This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Mike Stump <mikestump at comcast dot net>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 2 Sep 2013 13:18:26 +0200
- Subject: Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT
- Authentication-results: sourceware.org; auth=none
- References: <20130801150906 dot GB2236 at kam dot mff dot cuni dot cz> <441E5C9A-174E-4810-9F9C-F264E56170DF at comcast dot net> <20130822064756 dot GE16124 at kam dot mff dot cuni dot cz> <075DA2A7-0BFC-4455-B2DB-A50414DD95BD at comcast dot net> <20130902105208 dot GB5201 at kam dot mff dot cuni dot cz>
On Mon, Sep 2, 2013 at 12:52 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Aug 21, 2013, at 11:47 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >> 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.
>>
>> > 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.
>>
>> So, any news on this?
> I was bid dragged into other debuggning. Sorry for the delay.
> This patch seems to fix the problems on ppc64 hacked to not use asm thunks.
> Can you, please, test it that it solves problems on your target?
>
> Honza
>
> Index: cgraphunit.c
> ===================================================================
> --- cgraphunit.c (revision 202153)
> +++ cgraphunit.c (working copy)
> @@ -1414,14 +1414,18 @@ expand_thunk (struct cgraph_node *node)
> tree virtual_offset = NULL;
> tree alias = node->callees->callee->symbol.decl;
> tree thunk_fndecl = node->symbol.decl;
> - tree a = DECL_ARGUMENTS (thunk_fndecl);
> + tree a;
> +
> + if (in_lto_p)
> + cgraph_get_body (node);
That looks gross. It cannot possibly be the correct fix for this.
Richard.
> + a = DECL_ARGUMENTS (thunk_fndecl);
>
> current_function_decl = thunk_fndecl;
>
> /* Ensure thunks are emitted in their correct sections. */
> resolve_unique_section (thunk_fndecl, 0, flag_function_sections);
>
> - if (this_adjusting
> + if (this_adjusting
> && targetm.asm_out.can_output_mi_thunk (thunk_fndecl, fixed_offset,
> virtual_value, alias))
> {
> Index: lto-streamer-in.c
> ===================================================================
> --- lto-streamer-in.c (revision 202153)
> +++ lto-streamer-in.c (working copy)
> @@ -998,6 +998,7 @@ input_function (tree fn_decl, struct dat
> free_dominance_info (CDI_DOMINATORS);
> free_dominance_info (CDI_POST_DOMINATORS);
> free (stmts);
> + pop_cfun ();
> }
>
>
> @@ -1086,8 +1087,6 @@ lto_read_body (struct lto_file_decl_data
>
> /* Restore decl state */
> file_data->current_decl_state = file_data->global_decl_state;
> -
> - pop_cfun ();
> }
>
> lto_data_in_delete (data_in);
> Index: lto-streamer-out.c
> ===================================================================
> --- lto-streamer-out.c (revision 202153)
> +++ lto-streamer-out.c (working copy)
> @@ -1982,8 +1982,7 @@ lto_output (void)
> cgraph_node *node = dyn_cast <cgraph_node> (snode);
> if (node
> && lto_symtab_encoder_encode_body_p (encoder, node)
> - && !node->symbol.alias
> - && !node->thunk.thunk_p)
> + && !node->symbol.alias)
> {
> #ifdef ENABLE_CHECKING
> gcc_assert (!bitmap_bit_p (output, DECL_UID (node->symbol.decl)));