[Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

[Marek Olšák]

On Tue, Oct 18, 2016 at 7:12 PM, Jan Ziak <0xe2.0x9a.0x9b at gmail.com> wrote:
>> Regarding C++ templates, the compiler doesn't use them. If u_vector
>> (Dave Airlie?) provides the same functionality as your array, I
>> suggest we use u_vector instead.
>
> Let me repeat what you just wrote, because it is unbelievable: You are
> advising the use of non-templated collection types in C++ code.

Absolutely.

>
>> If you can't use u_vector, you should
>> ask for approval from GLSL compiler leads (e.g. Ian Romanick or
>> Kenneth Graunke) to use C++ templates.
>
> - You are talking about coding rules some Mesa developers agreed upon
> and didn't bother writing down for other developers to read
>
> - I am not willing to use u_vector in C++ code
>
>> I'll repeat some stuff about profiling here but also explain my perspective.
>
> So far (which may be a year or so), there is no indication that you
> are better at optimizing code than me.

Good one.

>
>> Never profile with -O0 or disabled function inlining.
>
> Seriously?

Absolutely.

>
>> Mesa uses -g -O2
>> with --enable-debug, so that's what you should use too. Don't use any
>> other -O* variants.
>
> What if I find a case where -O2 prevents me from easily seeing
> information necessary to optimize the source code?

There are several ways to get useful data from optimized code (using
the frame pointer, using dwarf, etc.) -O0 is too distorted.

>
>> The only profiling tools reporting correct results are perf and
>> sysprof.
>
> I used perf on Metro 2033 Redux and saw do_dead_code() there. Then I
> used callgrind to see some more code.

I recommend building Mesa with the frame pointer enabled, or enabling
dwarf in perf. Otherwise you won't see call trees.

>
>> (both use the same mechanism) If you don't enable dwarf in
>> perf (also sysprof can't use dwarf), you have to build Mesa with
>> -fno-omit-frame-pointer to see call trees. The only reason you would
>> want to enable dwarf-based call trees is when you want to see libc
>> calls. Otherwise, they won't be displayed or counted as part of call
>> trees. For Mesa developers who do profiling often,
>> -fno-omit-frame-pointer should be your default.
>
>> Callgrind counts calls (that one you can trust), but the reported time
>> is incorrect,
>
> Are you nuts? You cannot be seriously be assuming that I didn't know about that.
>
>> because it uses its own virtual model of a CPU. Avoid it
>> if you want to measure time spent in functions.
>
> I will *NOT* avoid callgrind because I know how to use it to optimize code.

I didn't suggest avoiding callgrind in all cases.

>
>>Marek
>
> As usual, I would like to notify reviewers&mergers of this path that I
> am not willing to wait months to learn whether the code will be merged
> or rejected.
>
> If it isn't merged by Thursday (2016-oct-20) I will mark it as
> rejected (rejected based on personal rather than scientific grounds).

Relax. Things tend to move slowly when people are on conferences,
vacations, or just busy with corporate stuff they have to deal with
every day etc. and you can't predict those.

Marek