| Message ID | 87h8ijktf4.fsf@oldenburg.str.redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | middle-end/81035: Mention that noreturn suppresses tail call optimization | expand |
On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote: > 2018-09-21 Florian Weimer <fweimer@redhat.com> > > PR middle-end/81035 > * doc/extend.texi (Common Function Attributes): Mention that > noreturn suppresses tail call optimization. > +In order to preserve backtraces, GCC will never turn calls to > +@code{noreturn} functions into tail calls. Should we document this? Shouldn't we fix it, instead? Segher
* Segher Boessenkool: > On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote: >> 2018-09-21 Florian Weimer <fweimer@redhat.com> >> >> PR middle-end/81035 >> * doc/extend.texi (Common Function Attributes): Mention that >> noreturn suppresses tail call optimization. > >> +In order to preserve backtraces, GCC will never turn calls to >> +@code{noreturn} functions into tail calls. > > Should we document this? Shouldn't we fix it, instead? Fix how? What is currently broken? For things like assertion failures, we do not want to replace the current stack frame with that of __assert_fail, I think. Thanks, Florian
> On Sep 21, 2018, at 2:17 PM, Florian Weimer <fweimer@redhat.com> wrote: > > * Segher Boessenkool: > >> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote: >>> 2018-09-21 Florian Weimer <fweimer@redhat.com> >>> >>> PR middle-end/81035 >>> * doc/extend.texi (Common Function Attributes): Mention that >>> noreturn suppresses tail call optimization. >> >>> +In order to preserve backtraces, GCC will never turn calls to >>> +@code{noreturn} functions into tail calls. >> >> Should we document this? Shouldn't we fix it, instead? > > Fix how? What is currently broken? > > For things like assertion failures, we do not want to replace the > current stack frame with that of __assert_fail, I think. I agree. Also, tailcalls are optimizations. Speed optimizing noreturn calls is obviously not interesting. Calls to noreturn functions are short, and turning them into a jump probably makes no difference in size, or if it does, not enough to matter. paul
* Paul Koning: >> On Sep 21, 2018, at 2:17 PM, Florian Weimer <fweimer@redhat.com> wrote: >> >> * Segher Boessenkool: >> >>> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote: >>>> 2018-09-21 Florian Weimer <fweimer@redhat.com> >>>> >>>> PR middle-end/81035 >>>> * doc/extend.texi (Common Function Attributes): Mention that >>>> noreturn suppresses tail call optimization. >>> >>>> +In order to preserve backtraces, GCC will never turn calls to >>>> +@code{noreturn} functions into tail calls. >>> >>> Should we document this? Shouldn't we fix it, instead? >> >> Fix how? What is currently broken? >> >> For things like assertion failures, we do not want to replace the >> current stack frame with that of __assert_fail, I think. > > I agree. Also, tailcalls are optimizations. Speed optimizing > noreturn calls is obviously not interesting. Calls to noreturn > functions are short, and turning them into a jump probably makes no > difference in size, or if it does, not enough to matter. The example in the bug report shows that tail calls can avoid setting up a stack frame, leading to smaller code size and CFI. Thanks, Florian
On 9/21/18 4:59 AM, Florian Weimer wrote: > 2018-09-21 Florian Weimer <fweimer@redhat.com> > > PR middle-end/81035 > * doc/extend.texi (Common Function Attributes): Mention that > noreturn suppresses tail call optimization. OK. jeff
On Fri, Sep 21, 2018 at 08:36:45PM +0200, Florian Weimer wrote: > * Paul Koning: > > >> On Sep 21, 2018, at 2:17 PM, Florian Weimer <fweimer@redhat.com> wrote: > >> > >> * Segher Boessenkool: > >> > >>> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote: > >>>> 2018-09-21 Florian Weimer <fweimer@redhat.com> > >>>> > >>>> PR middle-end/81035 > >>>> * doc/extend.texi (Common Function Attributes): Mention that > >>>> noreturn suppresses tail call optimization. > >>> > >>>> +In order to preserve backtraces, GCC will never turn calls to > >>>> +@code{noreturn} functions into tail calls. > >>> > >>> Should we document this? Shouldn't we fix it, instead? > >> > >> Fix how? What is currently broken? It prevents a useful optimisation for no good reason. > >> For things like assertion failures, we do not want to replace the > >> current stack frame with that of __assert_fail, I think. This isn't much different with all other tail calls. > > I agree. Also, tailcalls are optimizations. Speed optimizing > > noreturn calls is obviously not interesting. Calls to noreturn > > functions are short, and turning them into a jump probably makes no > > difference in size, or if it does, not enough to matter. > > The example in the bug report shows that tail calls can avoid setting up > a stack frame, leading to smaller code size and CFI. Yes. For example on PowerPC, *all* calls require the caller to have a stack frame. (This isn't different on other architectures' ABIs; it's just that we don't create stack frames implicitly). Avoiding to create a stack frame is a serious optimisation. With better shrink-wrapping it is less of an issue than it was in the past, but still. The whole point of tail calls is to destroy a stack frame. If that makes debugging too hard, then -Og should not create sibcalls. Only doing it for noreturn functions (and not only doing it in debug builds) doesn't make much sense IMO. Segher
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index e3312aa8b42..909e7a17357 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -3157,6 +3157,9 @@ The @code{noreturn} keyword does not affect the exceptional path when that applies: a @code{noreturn}-marked function may still return to the caller by throwing an exception or calling @code{longjmp}. +In order to preserve backtraces, GCC will never turn calls to +@code{noreturn} functions into tail calls. + Do not assume that registers saved by the calling function are restored before calling the @code{noreturn} function.