This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization
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