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

[Jan Ziak]

> 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.

> 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.

> Never profile with -O0 or disabled function inlining.

Seriously?

> 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?

> 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.

> (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.

>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).

Jan