Re: [LTO] Fix C++ thunks

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Wed, Dec 17, 2008 at 6:33 PM, Diego Novillo <dnovillo@google.com> wrote:
> [ CCing jason and mark, to make sure I'm not missing anything
>  obvious in the C++ side. ]
>
> This patch is the initial step to make thunks work with LTO.
> Essentially, this forces cc1plus to always emit non-asm thunks,
> which is a performance problem, but I think I know how to address
> it.
>
> Disabling non-asm thunks was not the only problem.  We were also
> emitting thunks too late in the pipeline, so they were never
> saved to disk.  So, we are now emitting thunks early in
> cgraph_optimize instead of doing it during expansion.

I posted a patch for this which was approved by Mark, on top of the
gimplification unit-at-a-time work.

> This fixes 32 tests in libstdc++ and produces two new failures in
> g++ (because non-asm thunks don't support varargs).

It should be possible to add this as we now have builtins to pass on
varargs properly.

> We've been chatting offline with Rafael and Ian discussing how to
> properly support asm-thunks.  Essentially, cp/method.c:use_thunk
> will always emit a new thunk function that contains exactly one
> gimple instruction: GIMPLE_THUNK_CALL.
>
> 1- GIMPLE_THUNK_CALL has at least four arguments: the thunk, the
>   target function, THUNK_FIXED_OFFSET, THUNK_VIRTUAL_OFFSET, and
>   in general anything that needs the C++ front end around.
>
> 2- Instead of emitting the offset adjusting code in use_thunk, we
>   will always emit just the GIMPLE_THUNK_CALL instruction.
>
> The call to GIMPLE_THUNK_CALL is then expanded in
> cgraph_expand_thunks, which will be now called *late* in
> cgraph_optimize.  This way, we can support emitting thunks out of
> lto1 and out of cc1plus.  This is important for this scenario:
>
> $ g++ -flto -c file.cc
> $ g++ file.o -o file
>
> file.o will contain two different versions of thunks.  In the IL
> sections, it will have the unexpanded GIMPLE_THUNK_CALL code.
> And in the final object code, it will have the asm thunks.
>
> This way, if the final link is not done with -flto, the thunks
> will be expanded as usual.
>
> Does this sound reasonable?

Well, I think you still will have interesting times to get all sibcalling
happening that the asm thunks support (which they do because you
generally do not want the frame of the thunk to appear in the call stack).

Richard.

>
>
> Thanks.  Diego.
>