Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Aug 4, 2010 at 10:15 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/04/2010 06:12 PM, H.J. Lu wrote:
>> On Wed, Aug 4, 2010 at 10:09 AM, Andrew Haley <aph@redhat.com> wrote:
>>> On 08/04/2010 06:07 PM, H.J. Lu wrote:
>>>> On Wed, Aug 4, 2010 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
>>>>> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>>>>>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>>>>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>>>>
>>>>>>>> I went through the defualt changing discussion at a time we was introducing
>>>>>>>> x86-64 port.
>>>>>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>>>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>>>>>> since most of packages adopted to 64bit world.
>>>>>>>>
>>>>>>>> Probably the most touchy issue concerning the switch is place
>>>>>>>> where you need stack unwinding fast. ?This is the case of oprofile
>>>>>>>> and some of garbage collector implementations.
>>>>>>>
>>>>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>>>>
>>>>>> I'll ask.
>>>>>
>>>>> For oprofile the answer is "Oprofile has a very simple-minded
>>>>> mechanism that uses the frame pointers to walk the stack. If the frame
>>>>> pointers are turned off, the call graph information oprofile generates
>>>>> will be pretty limited. The flat profiling will still work fine."
>>>>
>>>> Does oprofile work on Linux/x86-64? If yes, how does it walk the stack?
>>>
>>> Call graph information doesn't work on x86-64.
>>
>> So we get the same info as on Linux/x86-64. If it works on Linux/x86-64
>> in the future, it can also work on Linux/ia32 with -fomit-frame-pointer.
>
> Yes. ?I'm not really sure what point you're trying to make, though: it
> seems to be "x86-64 profiling is degraded, so we might as well degrade
> x86 as well." ?But that doesn't make any sense, so that can't be what
> you mean.
>

What I was trying to say are:

1. We chose to degrade x86-64 profiling for performance and it isn't
a big problem so that we want to compile x86-64 with -fno-omit-frame-pointer.
2. If we can do this for x86-64, we can also do it for ia32.
3. The unwind info is there and we can get it if we really want it.



-- 
H.J.