On Thu, Feb 14, 2019 at 1:41 AM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Thu, Feb 14, 2019 at 2:21 AM Ian Lance Taylor <i...@golang.org> wrote:
> >
> > Nikhil Benesch noticed that changes in the GCC backend were making the
> > use of defer functions that call recover less efficient. A defer
> > thunk is a generated function that looks like this (this is the entire
> > function body):
> >
> > if !runtime.setdeferretaddr(&L) {
> > deferredFunction()
> > }
> > L:
> >
> > The idea is that the address of the label passed to setdeferretaddr is
> > the address to which deferredFunction returns. The code in canrecover
> > compares the return address of the function to this saved address to
> > see whether the recover function can return non-nil. This is
> > explained in marginally more detail at
> > https://www.airs.com/blog/archives/376 .
> >
> > When the return address does not match, the canrecover code does a
> > more costly check that requires unwinding the stack. What Nikhil
> > Benesch noticed is that we were always taking that fallback.
> >
> > It turned out that the label address passed to setdeferretaddr was not
> > the label to which the deferred function would return. And that was
> > because the epilogue was being duplicated by the bb-reorder pass, and
> > the label was moved to one copy of the epilogue while the deferred
> > function returned to the other epilogue.
> >
> > Of course there is no reason to duplicate the epilogue in such a small
> > function. One easy way to disable that epilogue duplication is to
> > compile the function with -Os. That is what this patch does. This
> > patch compiles all thunks, not just defer thunks, with -Os, but since
> > they are all small that does no harm.
> >
> > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
> > to mainline.
>
> I think an easier way would have been to mark it with the cold attribute?
Maybe. The thunks aren't actually cold, though. It wouldn't make
sense to move the thunks to a cold part of the executable.
Ian
