Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT

[Jan Hubicka <hubicka at ucw dot cz>]

> So, I was tracking down an lto failure in the C++ test suite, g++.dg/ipa/pr46984.C, and it appears to be caused by 4df870fdeec85907db3dcabf1992cf8b63e1d562 aka svn+ssh://gcc.gnu.org/svn/gcc/trunk@201468.  I was trying to find the gcc-patches email for this work, but could not.  :-(  Anyway, the above is the closest work to that, that I can find.

I definitely wrote email with the description and I even remember Richard's reply on this.
I will dig it out.

> 
> The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv) is used during thunk code-generation, and thunk code-generation happens during the output of D::foo.
> 
> My port is a targetm.asm_out.can_output_mi_thunk false port.
> 
> RESULT_DECL is synthesized on the fly like this:
> 
>       /* Build the return declaration for the function.  */
>       restype = TREE_TYPE (TREE_TYPE (thunk_fndecl));
>       if (DECL_RESULT (thunk_fndecl) == NULL_TREE)
>         {
>           resdecl = build_decl (input_location, RESULT_DECL, 0, restype);
>           DECL_ARTIFICIAL (resdecl) = 1;
>           DECL_IGNORED_P (resdecl) = 1;
>           DECL_RESULT (thunk_fndecl) = resdecl;
>         }
>       else
>         resdecl = DECL_RESULT (thunk_fndecl);
> 
> in expand_thunk, but DECL_ARGUMENTS is not.  Either it needs to be, or it has to be saved and restored in some fashion.
> 
> input_function is never called for the thunk.  If it had been, then it would have worked I think.  I think this translates into output_function not being called on the thunk.

I see, I will try to modify i386 backend to not output thunks.  The problem
indeed is that thunks' arguments are built by the front-end and they are no
longer streamed.  I am surprised i386 survives this given that it also
produces some gimple thunks.

I guess easiest way around is to make them to be streamed same way as we stream
functions that are used as abstract origin.  I have different plans in this
direction - I want to lower thunks to gimple form early so they go through the
usual channel and get i.e. the profile read correctly.

I however recall some nasty issues with linker on Solaris triggering when the
relative order of thunk and function it is associated to in the assembly file
is changed.  So this probably should go in independently and with a care.

Honza