| Message ID | AANLkTinR6uC2_Vqd+_R17KO+_zL0+FwJFPYPLxu0Jkdc@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Jul 26, 2010 at 9:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Wed, Jul 14, 2010 at 2:55 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Wed, Jul 14, 2010 at 6:46 AM, H.J. Lu <hjl.tools@gmail.com> wrote: >>> On Wed, Jul 14, 2010 at 1:09 AM, Richard Guenther >>> <richard.guenther@gmail.com> wrote: >>>> On Tue, Jul 13, 2010 at 11:44 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>>>> On Tue, Jul 13, 2010 at 2:02 PM, Andrew Pinski <pinskia@gmail.com> wrote: >>>>>> On Tue, Jul 13, 2010 at 2:01 PM, Andrew Pinski <pinskia@gmail.com> wrote: >>>>>>> On Tue, Jul 13, 2010 at 1:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>>>>>>> What will stop working when -fomit-frame-pointer is on? >>>>>>> >>>>>>> backtraces when debugging information is not turned on. >>>>>> >>>>>> See http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01033.html and many >>>>>> more. This is not the first time this has been discussed. >>>>> >>>>> Most of 32bit x86 assembly codes in glibc have .eh_frame section. >>>>> If backtrace is absolutely needed, they can add -fasynchronous-unwind-tables >>>>> or -fno-omit-frame-pointer. >>>> >>>> We build opensuse with -fomit-frame-pointer -fasynchronous-unwind-tables. >>>> If you want to make -fomit-frame-pointer the default then you should enable >>>> unwind tables by default. >>>> >>> >>> I will try and make it target/OS dependent. >>> >> >> Here is a patch. How does it look? >> > > Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on > Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables > improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves > performance by up to 20%, but also increases code by up to 36%. > > This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if > -Os isn't used. > > Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk? Any comments on this patch. Any objections? Thanks. H.J. --- > Thanks. > > -- > H.J. > --- > gcc/ > > 2010-07-25 H.J. Lu <hongjiu.lu@intel.com> > > * config/i386/i386.c (override_options): For 32bit, default > flag_omit_frame_pointer and flag_asynchronous_unwind_tables > to TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT and > TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT. > > * config/i386/i386.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT): > New. > (TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise. > * config/i386/linux.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT): > Likewise. > (TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise. > * config/i386/linux64.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT): > Likewise. > (TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise. > > gcc/testsuite/ > > 2010-07-25 H.J. Lu <hongjiu.lu@intel.com> > > * gcc.target/i386/frame-pointer-1.c: New. > * gcc.target/i386/frame-pointer-2.c: Likewise. > * gcc.target/i386/frame-pointer-3.c: Likewise. > * gcc.target/i386/frame-pointer-4.c: Likewise. > * gcc.target/i386/frame-pointer-5.c: Likewise. >
On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on >> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables >> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves >> performance by up to 20%, but also increases code by up to 36%. >> >> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if >> -Os isn't used. >> >> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk? > > Any comments on this patch. Any objections? IMO, this should be approved by Release Managers, since this decision affects distributions and their users. I have no _technical_ objections to this patch, but I won't approve it either due to the reason above. Thanks, Uros.
On 08/03/2010 10:18 AM, Uros Bizjak wrote: > On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > >>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on >>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables >>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves >>> performance by up to 20%, but also increases code by up to 36%. >>> >>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if >>> -Os isn't used. >>> >>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk? >> >> Any comments on this patch. Any objections? > > IMO, this should be approved by Release Managers, since this decision > affects distributions and their users. > > I have no _technical_ objections to this patch, but I won't approve it > either due to the reason above. It's hard for us to know all the use cases that this patch will break: there may be many users who unwind the stack by following the call chain, a technique that has worked for many years. (And was even sanctioned by the ABI, wasn't it?) We'll know when if push this patch out and hear the screams. Is this really the right thing to do at this stage in the lifetime of legacy x86? Andrew.
On Tue, Aug 3, 2010 at 2:37 AM, Andrew Haley <aph@redhat.com> wrote: > On 08/03/2010 10:18 AM, Uros Bizjak wrote: >> On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> >>>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on >>>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables >>>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves >>>> performance by up to 20%, but also increases code by up to 36%. >>>> >>>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if >>>> -Os isn't used. >>>> >>>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk? >>> >>> Any comments on this patch. Any objections? >> >> IMO, this should be approved by Release Managers, since this decision >> affects distributions and their users. >> >> I have no _technical_ objections to this patch, but I won't approve it >> either due to the reason above. > > It's hard for us to know all the use cases that this patch will break: > there may be many users who unwind the stack by following the call > chain, a technique that has worked for many years. (And was even > sanctioned by the ABI, wasn't it?) We'll know when if push this patch > out and hear the screams. The psABI never guarantees it. If some code still depends on it today, we know how to fix it. > Is this really the right thing to do at this stage in the lifetime of > legacy x86? By the same token, it shouldn't be a big problem.
On Tue, Aug 3, 2010 at 2:18 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > >>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on >>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables >>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves >>> performance by up to 20%, but also increases code by up to 36%. >>> >>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if >>> -Os isn't used. >>> >>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk? >> >> Any comments on this patch. Any objections? > > IMO, this should be approved by Release Managers, since this decision > affects distributions and their users. > > I have no _technical_ objections to this patch, but I won't approve it > either due to the reason above. > Richard, Jakub, Mark, do you have any comments? Thanks.
H.J. Lu wrote:
> Richard, Jakub, Mark, do you have any comments?
I will review the thread today. Please give me some time to comment.
Thanks,
On Tue, Aug 03, 2010 at 07:03:34AM -0700, H.J. Lu wrote: > > It's hard for us to know all the use cases that this patch will break: > > there may be many users who unwind the stack by following the call > > chain, a technique that has worked for many years. (And was even > > sanctioned by the ABI, wasn't it?) We'll know when if push this patch > > out and hear the screams. > > The psABI never guarantees it. If some code still depends on it today, > we know how to fix it. I don't consider this an acceptable position for GCC. We have probably millions of users on x86. We can't make them update their code because of an environmental change in GCC. It's not simple to update code that relies on the frame pointer, and my experience on people porting from x86 to ARM or MIPS is that many companies have code which relies on backtracing via the frame pointer. I am opposed to the patch.
On Tue, Aug 3, 2010 at 7:18 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote: > On Tue, Aug 03, 2010 at 07:03:34AM -0700, H.J. Lu wrote: >> > It's hard for us to know all the use cases that this patch will break: >> > there may be many users who unwind the stack by following the call >> > chain, a technique that has worked for many years. (And was even >> > sanctioned by the ABI, wasn't it?) We'll know when if push this patch >> > out and hear the screams. >> >> The psABI never guarantees it. If some code still depends on it today, >> we know how to fix it. > > I don't consider this an acceptable position for GCC. We have > probably millions of users on x86. We can't make them update > their code because of an environmental change in GCC. It's not > simple to update code that relies on the frame pointer, and my > experience on people porting from x86 to ARM or MIPS is that many > companies have code which relies on backtracing via the frame pointer. > Their codes won't work on ARM/MIPS nor on x86 with other compilers. If this is a real problem, they can always turn it off. I don't think we hould punish majority of Linux/x86 users because of it.
On Tue, Aug 03, 2010 at 07:28:30AM -0700, H.J. Lu wrote: > Their codes won't work on ARM/MIPS nor on x86 with other > compilers. If this is a real problem, they can always turn it off. It is a real problem, there are many cases of it, and it only works if all the code in the system has frame pointers. Unpleasant, but that's the real world for you. This is something that matters to a lot of users.
On Tue, Aug 3, 2010 at 8:13 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote: > On Tue, Aug 03, 2010 at 07:28:30AM -0700, H.J. Lu wrote: >> Their codes won't work on ARM/MIPS nor on x86 with other >> compilers. If this is a real problem, they can always turn it off. > > It is a real problem, there are many cases of it, and it only works if > all the code in the system has frame pointers. Unpleasant, but that's > the real world for you. This is something that matters to a lot of users. > Exactly. There is nothing there saying that all libraries on Linux/x86 must have frame pointers. On some systems, frame pointers are omitted: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01128.html There is nothing wrong with that.
Mark Mitchell wrote:
> I will review the thread today. Please give me some time to comment.
I can certainly see both sides of this issue.
On the one hand, most users use "-O2" or "-O3", and we want those users
to see the best performance possible. It's not reasonable to expect
that most users will figure out that they can use -fomit-frame-pointer
to improve performance and add it in. My understanding is that some
distributions (e.g., OpenSuSE, IIUC) are now building the vast majority
of the distribution with -fomit-frame-pointer, but end users will not
necessarily know that they can/should use this option. The bottom line
is that -O2 should maximize performance.
On the other, changing this default will undoubtedly cause pain. As
Daniel said, we know that ARM and MIPS users have wrestled with the lack
of a frame pointer for some time. There is a surprising amount of code
that has built-in unwinders of various kinds. Being able to get
accurate backtraces from systems deployed in the field is essential for
many users. This code will break, silently, and people will be unhappy.
If I could, I'd go back in time and eliminate ABIs that use frame
pointers. The use of unwind tables is, IMHO, a clearly superior
solution. It provides for superior performance, and, for users
uninterested in backtraces, smaller code. (Even for users who do need
backtraces, it may result in a smaller cache footprint, since the unwind
tables will remain paged out most of the time.) But, we are where we
are, and we can't go back. So, the question is whether to make a
transition now, and, if so, how.
On balance, I think it's appropriate to make the change. I think
there's an overall move towards ABIs without frame pointers, and that if
x86 stakeholders want to change, it's not our place as GCC maintainers
to do this. The fact that major distributions are already building the
distribution itself (including its run-time libraries) without frame
pointers suggests that users must be adapting. And the fact that ARM
and MIPS users are still developing software suggests that people are
learning how to deal with unwind tables. So, it's a significant
transition, and there will be fallout, but it seems reasonable to me.
Ultimately, however, I don't think this is an RM question. I think it
should be determined by the x86 back-end maintainers. I'm happy to give
my input, and to help moderate a discussion if appropriate, but this
change does not affect any other architecture, so I think it's properly
a question for the x86 back-end maintainers.
On 08/03/2010 06:12 PM, Mark Mitchell wrote: > On balance, I think it's appropriate to make the change. I think > there's an overall move towards ABIs without frame pointers, and > that if x86 stakeholders want to change, it's not our place as GCC > maintainers to do this. Thanks for the carefully considered reply. A problem with "x86 stakeholders" is that we've historically been rather poor at finding our users and consulting them before making changes. This has resulted in a number of flamewars, particularly over type-based alias analysis. I wonder if this might be an opportunity to create a new best practice for gcc changes such as these by putting the decision out for consultation. I'm not quite sure how, though: obviously it's pretty easy for me to get opinions from Red Hat, but there may be a great many users we are totally unaware of. Andrew.
Hi Mark, Thanks for your inputs. On Tue, Aug 3, 2010 at 10:12 AM, Mark Mitchell <mark@codesourcery.com> wrote: > Mark Mitchell wrote: > >> I will review the thread today. Please give me some time to comment. > > I can certainly see both sides of this issue. > > On the one hand, most users use "-O2" or "-O3", and we want those users > to see the best performance possible. It's not reasonable to expect > that most users will figure out that they can use -fomit-frame-pointer > to improve performance and add it in. My understanding is that some > distributions (e.g., OpenSuSE, IIUC) are now building the vast majority > of the distribution with -fomit-frame-pointer, but end users will not > necessarily know that they can/should use this option. The bottom line > is that -O2 should maximize performance. > > On the other, changing this default will undoubtedly cause pain. As > Daniel said, we know that ARM and MIPS users have wrestled with the lack > of a frame pointer for some time. There is a surprising amount of code > that has built-in unwinders of various kinds. Being able to get > accurate backtraces from systems deployed in the field is essential for > many users. This code will break, silently, and people will be unhappy. > > If I could, I'd go back in time and eliminate ABIs that use frame > pointers. The use of unwind tables is, IMHO, a clearly superior Just for the reference, this is from i386 psABI: --- %ebp The frame pointer optionally holds a base address for the current stack frame. Consequently, a function has registers pointing to both ends of its frame. Incoming arguments reside in the previous frame, referenced as positive offsets from %ebp, while local variables reside in the current frame, referenced as negative offsets from %ebp. A function must preserve this register’s value for its caller. --- The stack layout at function entry is the same as x86-64 psABI. I understand the old backtrace codes depend on the frame pointer, but it isn't mandated by the psABI. > solution. It provides for superior performance, and, for users > uninterested in backtraces, smaller code. (Even for users who do need > backtraces, it may result in a smaller cache footprint, since the unwind > tables will remain paged out most of the time.) But, we are where we > are, and we can't go back. So, the question is whether to make a > transition now, and, if so, how. > > On balance, I think it's appropriate to make the change. I think > there's an overall move towards ABIs without frame pointers, and that if > x86 stakeholders want to change, it's not our place as GCC maintainers > to do this. The fact that major distributions are already building the > distribution itself (including its run-time libraries) without frame > pointers suggests that users must be adapting. And the fact that ARM > and MIPS users are still developing software suggests that people are > learning how to deal with unwind tables. So, it's a significant > transition, and there will be fallout, but it seems reasonable to me. > > Ultimately, however, I don't think this is an RM question. I think it > should be determined by the x86 back-end maintainers. I'm happy to give > my input, and to help moderate a discussion if appropriate, but this > change does not affect any other architecture, so I think it's properly > a question for the x86 back-end maintainers. > Thanks.
On Tue, Aug 3, 2010 at 10:24 AM, Andrew Haley <aph@redhat.com> wrote: > On 08/03/2010 06:12 PM, Mark Mitchell wrote: > >> On balance, I think it's appropriate to make the change. I think >> there's an overall move towards ABIs without frame pointers, and >> that if x86 stakeholders want to change, it's not our place as GCC >> maintainers to do this. > > Thanks for the carefully considered reply. > > A problem with "x86 stakeholders" is that we've historically been > rather poor at finding our users and consulting them before making > changes. This has resulted in a number of flamewars, particularly > over type-based alias analysis. > > I wonder if this might be an opportunity to create a new best practice > for gcc changes such as these by putting the decision out for > consultation. I'm not quite sure how, though: obviously it's pretty > easy for me to get opinions from Red Hat, but there may be a great > many users we are totally unaware of. > We definitely should help our users deal with this change. I only propose this for Linux/x86 where backstrace in glibc supports unwind table. We can show them how to use backstrace in glibc
H.J. Lu wrote: >> If I could, I'd go back in time and eliminate ABIs that use frame >> pointers. The use of unwind tables is, IMHO, a clearly superior > The stack layout at function entry is the same as x86-64 psABI. I understand > the old backtrace codes depend on the frame pointer, but it isn't mandated > by the psABI. Sure, but the psABI document is less relevant than existing practice. I don't think it's relevant to this discussion. Let's not talk about it. The important issue is that there is a lot of code out there that probably assumes a frame pointer, and it will stop working. We have to weigh that against the fact that the code that doesn't stop working will run faster. Thanks,
Andrew Haley wrote: >> On balance, I think it's appropriate to make the change. I think >> there's an overall move towards ABIs without frame pointers, and >> that if x86 stakeholders want to change, it's not our place as GCC >> maintainers to do this. > A problem with "x86 stakeholders" is that we've historically been > rather poor at finding our users and consulting them before making > changes. This has resulted in a number of flamewars, particularly > over type-based alias analysis. That's a general problem with free software: there are zillions of users, and we don't know where they are or what they want. I don't think there's a really great way to solve this problem, though there's no doubt an interesting Ph.D. thesis in there somewhere. One thing we could do pretty easily is to ask some distributions whether they will accept the change in defaults -- or undo it locally. If, for example, Red Hat product management is going to tweak the compiler so that it's default is -fno-omit-frame-pointer, in order to maintain backwards compatibility, then that's a valuable data point, since it means that Red Hat believes its customers would be unhappy with the change. On the other hand, if Debian says that they'll happily go along with the change, then that's a point in favor of making the change. So, maybe we need a poll of some of the most popular x86 Linux distributions, such as Debian, Red Hat, SuSe, and Ubuntu?
On 08/03/2010 10:24 AM, Andrew Haley wrote: > On 08/03/2010 06:12 PM, Mark Mitchell wrote: > >> On balance, I think it's appropriate to make the change. I think >> there's an overall move towards ABIs without frame pointers, and >> that if x86 stakeholders want to change, it's not our place as GCC >> maintainers to do this. > > Thanks for the carefully considered reply. > > A problem with "x86 stakeholders" is that we've historically been > rather poor at finding our users and consulting them before making > changes. This has resulted in a number of flamewars, particularly > over type-based alias analysis. > It may even be possible to preemptively generate a flamewar with a post to something like the LKML laying out the pros and cons. It is a change to the de facto ABI. Think back to what happened with the x86 direction flag issue. David Daney
On 08/03/2010 10:12 AM, Mark Mitchell wrote: > Ultimately, however, I don't think this is an RM question. I think it > should be determined by the x86 back-end maintainers. I'm happy to give > my input, and to help moderate a discussion if appropriate, but this > change does not affect any other architecture, so I think it's properly > a question for the x86 back-end maintainers. For the last week or so I've been trying to help ktietz with preparing the x86_64 backend for Structured Exception Handling and the unwind tables that win64 uses. In the process of reading over the MS documentation, it appears that the MS compiler is no longer producing the traditional frame pointer. Indeed, even when they *do* generate a frame pointer, its position in the frame is lower than usual. The advantage being that more of the local stack frame is addressable via RBP + 8-bit-offset, leading to smaller code. I think it would be very nice to be able to make this change in GCC as well. In order to do this, I would very much like to wean users off using the traditional frame pointer and instead rely on the various unwind libraries. That MS programmers will now be forced to think in that direction helps, I think. Given that if a user files a bug we can always point them to a switch to re-enable the traditional frame pointer, count me as in favor of the patch. r~
On 08/03/2010 06:57 PM, Mark Mitchell wrote: > Andrew Haley wrote: > >>> On balance, I think it's appropriate to make the change. I think >>> there's an overall move towards ABIs without frame pointers, and >>> that if x86 stakeholders want to change, it's not our place as GCC >>> maintainers to do this. > >> A problem with "x86 stakeholders" is that we've historically been >> rather poor at finding our users and consulting them before making >> changes. This has resulted in a number of flamewars, particularly >> over type-based alias analysis. > > That's a general problem with free software: there are zillions of > users, and we don't know where they are or what they want. I don't > think there's a really great way to solve this problem, though there's > no doubt an interesting Ph.D. thesis in there somewhere. > > One thing we could do pretty easily is to ask some distributions whether > they will accept the change in defaults -- or undo it locally. If, for > example, Red Hat product management is going to tweak the compiler so > that it's default is -fno-omit-frame-pointer, in order to maintain > backwards compatibility, then that's a valuable data point, since it > means that Red Hat believes its customers would be unhappy with the > change. On the other hand, if Debian says that they'll happily go along > with the change, then that's a point in favor of making the change. > > So, maybe we need a poll of some of the most popular x86 Linux > distributions, such as Debian, Red Hat, SuSe, and Ubuntu? I propose to raise this matter on the LKML. Does anyone think this would be a bad idea? Andrew.
Andrew Haley wrote: >> So, maybe we need a poll of some of the most popular x86 Linux >> distributions, such as Debian, Red Hat, SuSe, and Ubuntu? > > I propose to raise this matter on the LKML. Does anyone think this > would be a bad idea? You certainly don't need permission to raise the issue where you think might be helpful. But, is LKML a particularly good place? This issue isn't going to affect kernel developers; my understanding is that the kernel still needs frame pointers, but whether or not it does, the kernel people will put the right option in their Makefiles. This is really a question for userspace developers, with their uncountably vast number of applications and libraries.
On 08/04/2010 03:29 PM, Mark Mitchell wrote: > Andrew Haley wrote: > >>> So, maybe we need a poll of some of the most popular x86 Linux >>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu? >> >> I propose to raise this matter on the LKML. Does anyone think this >> would be a bad idea? > > You certainly don't need permission to raise the issue where you > think might be helpful. But, is LKML a particularly good place? > This issue isn't going to affect kernel developers; my understanding > is that the kernel still needs frame pointers, but whether or not it > does, the kernel people will put the right option in their > Makefiles. This is really a question for userspace developers, with > their uncountably vast number of applications and libraries. Well, LKML would be a starting place, and they are a group of users that has screamed about such changes in the past. However, I take your point. Perhaps fedora-devel would be a good place for me to start: it's in my back yard, anyway. Andrew.
On 08/04/2010 04:29 PM, Mark Mitchell wrote: > But, is LKML a particularly good place? This issue > isn't going to affect kernel developers; my understanding is that the > kernel still needs frame pointers, but whether or not it does, the > kernel people will put the right option in their Makefiles. config FRAME_POINTER bool "Compile the kernel with frame pointers" depends on DEBUG_KERNEL && \ (X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ AVR32 || SUPERH || BLACKFIN || MN10300) default y if DEBUG_INFO && UML help If you say Y here the resulting kernel image will be slightly larger and slower, but it might give very useful debugging information on some architectures or if you use external debuggers. If you don't debug the kernel, you can say N. Bernd
> Andrew Haley wrote: > > >> On balance, I think it's appropriate to make the change. I think > >> there's an overall move towards ABIs without frame pointers, and > >> that if x86 stakeholders want to change, it's not our place as GCC > >> maintainers to do this. > > > A problem with "x86 stakeholders" is that we've historically been > > rather poor at finding our users and consulting them before making > > changes. This has resulted in a number of flamewars, particularly > > over type-based alias analysis. > > That's a general problem with free software: there are zillions of > users, and we don't know where they are or what they want. I don't > think there's a really great way to solve this problem, though there's > no doubt an interesting Ph.D. thesis in there somewhere. > > One thing we could do pretty easily is to ask some distributions whether > they will accept the change in defaults -- or undo it locally. If, for > example, Red Hat product management is going to tweak the compiler so > that it's default is -fno-omit-frame-pointer, in order to maintain > backwards compatibility, then that's a valuable data point, since it > means that Red Hat believes its customers would be unhappy with the > change. On the other hand, if Debian says that they'll happily go along > with the change, then that's a point in favor of making the change. > > So, maybe we need a poll of some of the most popular x86 Linux > distributions, such as Debian, Red Hat, SuSe, and Ubuntu? 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. Honza > > -- > Mark Mitchell > CodeSourcery > mark@codesourcery.com > (650) 331-3385 x713
On 08/04/2010 03:59 PM, Jan Hubicka wrote: >> >> So, maybe we need a poll of some of the most popular x86 Linux >> distributions, such as Debian, Red Hat, SuSe, and Ubuntu? > > 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. I don't dispute that this is the best default for all new arches. However, 32-bit x86 is a legacy arch, with a lot of dusty old code. > 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. Ah, yes. Andrew.
On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> Andrew Haley wrote: >> >> >> On balance, I think it's appropriate to make the change. I think >> >> there's an overall move towards ABIs without frame pointers, and >> >> that if x86 stakeholders want to change, it's not our place as GCC >> >> maintainers to do this. >> >> > A problem with "x86 stakeholders" is that we've historically been >> > rather poor at finding our users and consulting them before making >> > changes. This has resulted in a number of flamewars, particularly >> > over type-based alias analysis. >> >> That's a general problem with free software: there are zillions of >> users, and we don't know where they are or what they want. I don't >> think there's a really great way to solve this problem, though there's >> no doubt an interesting Ph.D. thesis in there somewhere. >> >> One thing we could do pretty easily is to ask some distributions whether >> they will accept the change in defaults -- or undo it locally. If, for >> example, Red Hat product management is going to tweak the compiler so >> that it's default is -fno-omit-frame-pointer, in order to maintain >> backwards compatibility, then that's a valuable data point, since it >> means that Red Hat believes its customers would be unhappy with the >> change. On the other hand, if Debian says that they'll happily go along >> with the change, then that's a point in favor of making the change. >> >> So, maybe we need a poll of some of the most popular x86 Linux >> distributions, such as Debian, Red Hat, SuSe, and Ubuntu? > > 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. As for "some garbage collector implementations", do they work on Linux/x86-64? Do they work with icc on 32bit Linux/x86?
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: >>> Andrew Haley wrote: >>> >>>>> On balance, I think it's appropriate to make the change. I think >>>>> there's an overall move towards ABIs without frame pointers, and >>>>> that if x86 stakeholders want to change, it's not our place as GCC >>>>> maintainers to do this. >>> >>>> A problem with "x86 stakeholders" is that we've historically been >>>> rather poor at finding our users and consulting them before making >>>> changes. This has resulted in a number of flamewars, particularly >>>> over type-based alias analysis. >>> >>> That's a general problem with free software: there are zillions of >>> users, and we don't know where they are or what they want. I don't >>> think there's a really great way to solve this problem, though there's >>> no doubt an interesting Ph.D. thesis in there somewhere. >>> >>> One thing we could do pretty easily is to ask some distributions whether >>> they will accept the change in defaults -- or undo it locally. If, for >>> example, Red Hat product management is going to tweak the compiler so >>> that it's default is -fno-omit-frame-pointer, in order to maintain >>> backwards compatibility, then that's a valuable data point, since it >>> means that Red Hat believes its customers would be unhappy with the >>> change. On the other hand, if Debian says that they'll happily go along >>> with the change, then that's a point in favor of making the change. >>> >>> So, maybe we need a poll of some of the most popular x86 Linux >>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu? >> >> 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. > As for "some garbage collector implementations", do they work on > Linux/x86-64? Do they work with icc on 32bit Linux/x86? >
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." Andrew.
On 08/04/2010 06:05 PM, Andrew Haley 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." And for systemtap and java: "systemtap uses .eh_frame/.debug_frame unwind info to get backtraces (both kernel and user space), so that should be fine with/without framepointers (but kind of relies on -fasynchronous-unwind-tables, which is the default on fedora/rhel). The jstack support for hotspot relies on frame_pointers being generated by the JITs (which isn't always true, but it can often recover when it finds a frame that doesn't have one)." Andrew.
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?
On Aug 4, 2010, at 10:05 AM, Andrew Haley 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." FWIW, this is one of the main reasons why Darwin/i386 still uses frame pointers for the whole OS stack. The kernel based profiler (shark) doesn't want to grovel through eh frame info from kernel space. This means that -fomit-frame-pointers severely harms whole-system profiling on i386, which was considered unacceptable. -Chris
On Wed, Aug 4, 2010 at 10:06 AM, Andrew Haley <aph@redhat.com> wrote: > On 08/04/2010 06:05 PM, Andrew Haley 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." > > And for systemtap and java: > > "systemtap uses .eh_frame/.debug_frame unwind info to get backtraces > (both kernel and user space), so that should be fine with/without > framepointers (but kind of relies on -fasynchronous-unwind-tables, which > is the default on fedora/rhel). The jstack support for hotspot relies on > frame_pointers being generated by the JITs (which isn't always true, but > it can often recover when it finds a frame that doesn't have one)." > Does jstack work on Linux/x86-64?
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. Andrew.
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.
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. Andrew.
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. Lu" <hjl.tools@gmail.com> writes: > > Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. It doesn't for user space. The problem is that you would need an in kernel dwarf2 unwinder that reads user space tables. x86-64 suffers from this already. However there are some alternative approaches being explored for this, like using LBRs. -Andi
On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote: > "H.J. Lu" <hjl.tools@gmail.com> writes: >> >> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. > > It doesn't for user space. The problem is that you would need > an in kernel dwarf2 unwinder that reads user space tables. > > x86-64 suffers from this already. > But it is considered acceptable so that we still want -fomit-frame-pointer for Linux/x86-64.
On 08/04/2010 06:41 PM, H.J. Lu wrote: > On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote: >> "H.J. Lu" <hjl.tools@gmail.com> writes: >>> >>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. >> >> It doesn't for user space. The problem is that you would need >> an in kernel dwarf2 unwinder that reads user space tables. >> >> x86-64 suffers from this already. > > But it is considered acceptable By whom? > so that we still want -fomit-frame-pointer for Linux/x86-64. Ah, so your argument *is* "x86-64 profiling is degraded, so we might as well degrade x86 as well." Andrew.
On Wed, Aug 4, 2010 at 10:47 AM, Andrew Haley <aph@redhat.com> wrote: > On 08/04/2010 06:41 PM, H.J. Lu wrote: >> On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote: >>> "H.J. Lu" <hjl.tools@gmail.com> writes: >>>> >>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. >>> >>> It doesn't for user space. The problem is that you would need >>> an in kernel dwarf2 unwinder that reads user space tables. >>> >>> x86-64 suffers from this already. >> > >> But it is considered acceptable > > By whom? By people's action. > >> so that we still want -fomit-frame-pointer for Linux/x86-64. > > Ah, so your argument *is* "x86-64 profiling is degraded, so we might > as well degrade x86 as well." > Yes, especially when it gives some nice performance improvement. Can you tell me which gcc optimization can give you 4% speedup in most applications?
On Wed, Aug 04, 2010 at 06:47:19PM +0100, Andrew Haley wrote: > On 08/04/2010 06:41 PM, H.J. Lu wrote: > > On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote: > >> "H.J. Lu" <hjl.tools@gmail.com> writes: > >>> > >>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. > >> > >> It doesn't for user space. The problem is that you would need > >> an in kernel dwarf2 unwinder that reads user space tables. > >> > >> x86-64 suffers from this already. > > > > > But it is considered acceptable > > By whom? > > > so that we still want -fomit-frame-pointer for Linux/x86-64. > > Ah, so your argument *is* "x86-64 profiling is degraded, so we might > as well degrade x86 as well." It's not a totally unreasonable argument. The right action would be probably to attack the problem properly for both. -Andi
Andi Kleen wrote: >> Ah, so your argument *is* "x86-64 profiling is degraded, so we might >> as well degrade x86 as well." > > It's not a totally unreasonable argument. I agree; you can reason as follows: * We are not going to change the 64-bit ABI. * We really want profiling to work on the 64-bit ABI. * Therefore, we must fix profiling for the 64-bit ABI so that it works well without a frame pointer. * That solution will probably work well on the 32-bit ABI too. But, then there is a reasonable question about ordering. If that's the plan, then perhaps profiling should be fixed first, so that 32-bit users don't lose that ability until someone gets around to fixing profiling without a frame pointer. On the other hand, maybe 32-bit users would like their performance increase now. HJ, I don't think your arguments are persuasive in themselves. There is not a completely obvious right answer here and simply tossing out the same arguments doesn't make them more obviously right. This is a question about what's good for users; whether they benefit more by the performance improvement than they lose by the change in ABI and code breakage and associated loss of functionality. My instinct on this issue remains that we should make the change, but I don't claim that's obvious. The only way I can see to get a scientific answer (as opposed to "my instinct is" answer) is to talk to actual users. Please either go do that, or else let's ask RTH, Uros, and Jan to vote; we've got three x86 maintainers, so if they all vote, we can't have a tie...
On Wed, Aug 4, 2010 at 11:11 AM, Mark Mitchell <mark@codesourcery.com> wrote: > Andi Kleen wrote: > >>> Ah, so your argument *is* "x86-64 profiling is degraded, so we might >>> as well degrade x86 as well." >> >> It's not a totally unreasonable argument. > > I agree; you can reason as follows: > > * We are not going to change the 64-bit ABI. > * We really want profiling to work on the 64-bit ABI. > * Therefore, we must fix profiling for the 64-bit ABI so that it works > well without a frame pointer. > * That solution will probably work well on the 32-bit ABI too. > > But, then there is a reasonable question about ordering. If that's the > plan, then perhaps profiling should be fixed first, so that 32-bit users > don't lose that ability until someone gets around to fixing profiling > without a frame pointer. On the other hand, maybe 32-bit users would > like their performance increase now. > > HJ, I don't think your arguments are persuasive in themselves. There is > not a completely obvious right answer here and simply tossing out the > same arguments doesn't make them more obviously right. This is a > question about what's good for users; whether they benefit more by the > performance improvement than they lose by the change in ABI and code > breakage and associated loss of functionality. > > My instinct on this issue remains that we should make the change, but I > don't claim that's obvious. The only way I can see to get a scientific > answer (as opposed to "my instinct is" answer) is to talk to actual users. ICC has made -fomit-frame-pointer the default on 32bit for a quite while. I can ask ICC people if they have any complaints from their users. > Please either go do that, or else let's ask RTH, Uros, and Jan to vote; > we've got three x86 maintainers, so if they all vote, we can't have a tie... > That sounds a good idea.
H.J. Lu <hjl.tools <at> gmail.com> writes: > On Wed, Aug 4, 2010 at 10:06 AM, Andrew Haley <aph <at> redhat.com> wrote: > > On 08/04/2010 06:05 PM, Andrew Haley wrote: > > And for systemtap and java: > > > > "systemtap uses .eh_frame/.debug_frame unwind info to get backtraces > > (both kernel and user space), so that should be fine with/without > > framepointers (but kind of relies on -fasynchronous-unwind-tables, which > > is the default on fedora/rhel). The jstack support for hotspot relies on > > frame_pointers being generated by the JITs (which isn't always true, but > > it can often recover when it finds a frame that doesn't have one)." > > > > Does jstack work on Linux/x86-64? Yes. The systemtap jstack support relies on the code generated by the java hotspot code generator. It walks "java frames". So it doesn't matter (much) what gcc generated itself. In theory it would break down if a non-java frame sneaks in without an explicit frame-pointer (like JNI code). gcc on x86_64 doesn't generate them, but we haven't heard much complains (jstack tries to recover and guess the next stack frame). If there are complaints it is too unreliable jstack might be extended to find/use the (java) stack frame data from the hotspot runtime (which already has to deal with unwinding through mixed java/native code without frame-pointers. Or it could try reusing the systemtap support for walking the user stack through CFIs for those "native" frames. Cheers, Mark
On Wed, 4 Aug 2010, Andi Kleen wrote: > > Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. > > It doesn't for user space. The problem is that you would need > an in kernel dwarf2 unwinder that reads user space tables. > > x86-64 suffers from this already. > > However there are some alternative approaches being explored for this, > like using LBRs. I don't know what a LBR is, but FWIW, it looks to me like a scenario asking for a userspace daemon interpreting raw address/stack information passed on from the kernel. The daemon could use whatever complex tools are needed to interpret the information received or just dump it somewhere in a form complete enough for later post-processing (e.g. if the tools required were not fast enough to cope in real time). Just because while in some cases it seems easier to code (hack) things into the kernel, it does not necessarily mean they should be there. The fewer things in the kernel the better. Just IMHO. Maciej
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index dbb8949..640243e 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -2985,10 +2985,27 @@ override_options (bool main_args_p) { if (flag_zee == 2) flag_zee = 0; + /* Unwind info is not correct around the CFG unless either a + frame pointer is present or -maccumulate-outgoing-args is + set. When both -fasynchronous-unwind-tables and + -fomit-frame-pointer are turned on by default, turn off + both if -mno-accumulate-outgoing-args is used. When + optimizing for size, don't turn on -fomit-frame-pointer nor + -fasynchronous-unwind-tables by default. */ if (flag_omit_frame_pointer == 2) - flag_omit_frame_pointer = 0; + flag_omit_frame_pointer + = (!optimize_size + && TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT + && (!TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT + || !(target_flags_explicit + & MASK_ACCUMULATE_OUTGOING_ARGS))); if (flag_asynchronous_unwind_tables == 2) - flag_asynchronous_unwind_tables = 0; + flag_asynchronous_unwind_tables + = (!optimize_size + && TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT + && (!TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT + || !(target_flags_explicit + & MASK_ACCUMULATE_OUTGOING_ARGS))); if (flag_pcc_struct_return == 2) flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN; } diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index e153920..2bb6d3e 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -467,6 +467,8 @@ extern tree x86_mfence; /* Extra bits to force on w/ 32-bit mode. */ #define TARGET_SUBTARGET32_DEFAULT 0 #define TARGET_SUBTARGET32_ISA_DEFAULT 0 +#define TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT 0 +#define TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT 0 /* Extra bits to force on w/ 64-bit mode. */ #define TARGET_SUBTARGET64_DEFAULT 0 diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h index 81dfd1e..61d53b5 100644 --- a/gcc/config/i386/linux.h +++ b/gcc/config/i386/linux.h @@ -219,3 +219,10 @@ along with GCC; see the file COPYING3. If not see /* i386 glibc provides __stack_chk_guard in %gs:0x14. */ #define TARGET_THREAD_SSP_OFFSET 0x14 #endif + +/* Turn on -fomit-frame-pointer and -fasynchronous-unwind-tables by + default. */ +#undef TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT +#define TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT 1 +#undef TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT +#define TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT 1 diff --git a/gcc/config/i386/linux64.h b/gcc/config/i386/linux64.h index 33b4dc9..5a02205 100644 --- a/gcc/config/i386/linux64.h +++ b/gcc/config/i386/linux64.h @@ -123,3 +123,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see x86_64 glibc provides it in %fs:0x28. */ #define TARGET_THREAD_SSP_OFFSET (TARGET_64BIT ? 0x28 : 0x14) #endif + +/* Turn on -fomit-frame-pointer and -fasynchronous-unwind-tables by + default. */ +#undef TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT +#define TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT 1 +#undef TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT +#define TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT 1 diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-1.c b/gcc/testsuite/gcc.target/i386/frame-pointer-1.c new file mode 100644 index 0000000..ed4bff6 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/frame-pointer-1.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -mtune=i686" } */ +/* { dg-require-effective-target ilp32 } */ + +void bar (int); + +void +foo (void) +{ + bar (1); +} + +/* { dg-final { scan-assembler-not "pushl\[\\t \]*%ebp" } } */ diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-2.c b/gcc/testsuite/gcc.target/i386/frame-pointer-2.c new file mode 100644 index 0000000..b951ff4 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/frame-pointer-2.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -mtune=i686 -mno-accumulate-outgoing-args" } */ +/* { dg-require-effective-target ilp32 } */ + +void bar (int); + +void +foo (void) +{ + bar (1); +} + +/* { dg-final { scan-assembler "pushl\[\\t \]*%ebp" } } */ diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-3.c b/gcc/testsuite/gcc.target/i386/frame-pointer-3.c new file mode 100644 index 0000000..7a1d4d1 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/frame-pointer-3.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -mtune=i686 -mpush-args" } */ +/* { dg-require-effective-target ilp32 } */ + +void bar (int); + +void +foo (void) +{ + bar (1); +} + +/* { dg-final { scan-assembler-not "pushl\[\\t \]*%ebp" } } */ diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-4.c b/gcc/testsuite/gcc.target/i386/frame-pointer-4.c new file mode 100644 index 0000000..330a9ce --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/frame-pointer-4.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -mtune=i686 -mpush-args -mno-accumulate-outgoing-args" } */ +/* { dg-require-effective-target ilp32 } */ + +void bar (int); + +void +foo (void) +{ + bar (1); +} + +/* { dg-final { scan-assembler "pushl\[\\t \]*%ebp" } } */ diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-5.c b/gcc/testsuite/gcc.target/i386/frame-pointer-5.c new file mode 100644 index 0000000..11240a2 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/frame-pointer-5.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-options "-Os -mtune=i686" } */ +/* { dg-require-effective-target ilp32 } */ + +void bar (int); + +void +foo (void) +{ + bar (1); +} + +/* { dg-final { scan-assembler "pushl\[\\t \]*%ebp" } } */