Re: Finding the optimization that is making the change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 11, 2017 at 1:15 PM, Will Hawkins <whh8b@xxxxxxxxxxxx> wrote:
> On Fri, Aug 11, 2017 at 1:14 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
>> On 11 August 2017 at 18:09, Will Hawkins <whh8b@xxxxxxxxxxxx> wrote:
>>> Hello everyone!
>>>
>>> First, thank you all for your participation in the gcc community -- I
>>> firmly believe that one of the great strengths of free software is the
>>> community of people that participate in its development, maintenance
>>> and support. So, thank you!
>>>
>>> I have a simple C program and I am attempting to determine which of
>>> the optimizations at O1 cause a particular transformation. In order to
>>> isolate the optimizations enabled at O1 vs O0, I followed an idea set
>>> out in the gcc man page and ran the following command:
>>>
>>> $ diff <(gcc -Q -O1 --help=optimizers) <(gcc -Q --help=optimizers) |
>>> grep enabled | awk '{print $2;}' > optimizations
>>>
>>> Then I compiled with the following command:
>>>
>>> gcc -o scfi.poptim `cat optimizations | tr '\n' ' '` scfi.c
>>>
>>> I compared simple.poptim with simple.optim that came from running this command:
>>>
>>> gcc -o simple.optim -O1 simple.c
>>>
>>> I expected that simple.optim and simple.poptim would be (largely)
>>> identical. That is not the case, however. It does not look like the
>>> scfi.poptim program has been optimized at all.
>>
>> Because you didn't specify any -O optimization option, which means
>> there is no optimization done at all. See
>> https://gcc.gnu.org/wiki/FAQ#optimization-options
>>
>> Options to enable/disable individual optimizations have no effect if
>> the optimizers aren't run at all.
>>
>>> I was wondering if anyone could shed some light on why this is not the
>>> case. I ask only because the gcc man page seems to imply that this is
>>> the "right" way to isolate the different optimizations performed at
>>> different levels.
>>
>> No, you need to use -O1 -fno-xxx -fno-yyy -fno-zzz
>>
>> i.e. turn on optimization, then disable individual passes. You can't
>> start from nothing and enable individual ones, that gives you nothing.
>
> Wow! That makes perfect sense. Thank you so much! I will give it a try
> and let you know what I find. Thanks for the quick response!

I tried your suggestion and I am still getting very odd behavior. I
have essentially done the opposite of what I was doing before.

gcc -o scfi.poptim -O1 `cat optimizations | sed -e 's/^-f/-fno-/' | tr
'\n' ' '` scfi.c

which yields the following invocation:

gcc -o scfi.poptim -O1 -fno-combine-stack-adjustments
-fno-compare-elim -fno-cprop-registers -fno-defer-pop
-fno-forward-propagate -fno-guess-branch-probability
-fno-if-conversion -fno-if-conversion2
-fno-inline-functions-called-once -fno-ipa-profile -fno-ipa-pure-const
-fno-ipa-reference -fno-merge-constants -fno-shrink-wrap
-fno-split-wide-types -fno-tree-bit-ccp -fno-tree-ccp -fno-tree-ch
-fno-tree-copy-prop -fno-tree-copyrename -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-fre -fno-tree-sink
-fno-tree-slsr -fno-tree-sra -fno-tree-ter scfi.c

I would have expected that to build the (largely) same binary as

 gcc -o scfi -O0 scfi.c

and yet it does not. The former is still optimized and the latter is
(obviously) not.

Sorry to ask such stupid questions. This behavior just doesn't seem to
make much sense.

Thanks again for all your help, everyone!
Will


>
> Will



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux