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

[Eero Tamminen]

Hi,

On 18.10.2016 16:25, Jan Ziak wrote:
> On Tue, Oct 18, 2016 at 3:12 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 18.10.2016 15:07, Jan Ziak wrote:
>>> On Tue Oct 18 09:29:59 UTC 2016, Eero Tamminen wrote:
>>>> On 18.10.2016 01:07, Jan Ziak wrote:
>>>>> - The total number of executed instructions goes down from 64.184 to
>>>>> 63.797
>>>>>   giga-instructions when Mesa is compiled with "gcc -O0 ..."
>>>>
>>>> Please don't do performance related decisions based on data from
>>>> compiling code with optimizations disabled.  Use -O2 or -O3 (or even
>>>> better, check both).
>>>
>>> Options -O2 and -O3 interfere with profiling tools.
>>>
>>> I will try using -Og the next time.
>>
>> Just stop and use proper profiling tools like perf that can work with
>> optimized tools.

Valgrind/callgrind/cachegrind works also fine with optimized binaries.

All profiling tools lie, at least a bit. It's better to know their 
strengths and weaknesses so that one knows which ones complement each 
other. Perf is e.g. good at finding hotspots, Valgrind (callgrind) is 
more reliable in telling how they get called.

One may also needs GCC version from this decade.  Really old GCC 
versions didn't inlude all debug info needed for debugging optimized 
binaries.


>> You may have to compile with -fno-omit-frame-pointer, but
>> anything more than that is going to distort your measurement results so much
>> that they're worthless.
 >
> The function from -O0, -O1, -O2 to number-of-instructions (or to
> number-of-cycles) is in the vast majority of cases a monotonically
> decreasing function.
 >
 > Are you saying that this rule does not hold in the case of this patch?

-O1 puts variables into registers instead of using them directly from 
stack like -O0 does.  -O3 adds things like inlining and aliasing 
analysis.  Only higher optimization levels do dead code analysis. 
Whether these increase or decrease code side, depends on the code.


	- Eero