This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 22 May 2014 17:36:52 +0200
- Subject: Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
- Authentication-results: sourceware.org; auth=none
- References: <20140521131634 dot 178838544 at virgil dot suse dot cz> <20140521131634 dot 646352575 at virgil dot suse dot cz> <CAFiYyc3m-NLuKYcA65WKrONJsimRkrqPSN8XN5bRg99RTG9_jw at mail dot gmail dot com> <20140522124952 dot GA13095 at virgil dot suse> <CAFiYyc3FXT0VNQDst=Q8rZ5Y1+vNwhgGHcoJFMdfz6dbVV1OjQ at mail dot gmail dot com> <20140522152433 dot GB19612 at kam dot mff dot cuni dot cz>
On May 22, 2014 5:24:33 PM CEST, Jan Hubicka <email@example.com> wrote:
>> Can we? If the body is not readily available we only have decl and
>> cgraph-node, not struct function.
>> I suppose we could exchange the struct function pointer in
>> tree_function_decl for a cgraph_node pointer and put
>> the struct function pointer into the cgraph_node.
>> Of course that may have impacts on FEs who might create
>> struct function before creating a cgraph node. But at least
>> it would avoid enlarging FUNCTION_DECL.
>> In the end most of the tree_decl_with_vis stuff should move over to
>> and var-decls should get a varpool_node pointer as well.
>> Back to the call flags stuff - I also meant the representation of the
>> "fn spec" attribute. Rather than parsing that again and again move
>> it to a better place (which you seem to invent?) and better unified
>> Can you try if removing the cgraph hash is possible with the
>> struct function pointer idea?
>It won't be so easy, because struct function is really built at
>places within frontend before cgraph node is assigned to them (I tried
>that few years
Well, just call cgraph create node from struct Funktion allocation.
>I think we may be on better track moving DECL_ASSEMBLER_NAME that is
>but then we have problem with DECL_ASSEMBLER_NAME being set for
>assembler names and
>const decls, too that still go around symtab.
>Given that decl_assembler_name is a function, I suppose we could go
>with extra conditoinal
>Getting struct function out of frontend busyness would be nice indeed,
>too, but probably
>should be independent of Martin's work here.
>> > Thanks,
>> > Martin
>> >> > + }
>> >> > }
>> >> > +
>> >> > + return ret;
>> >> > }
>> >> >
>> >> > /* Detects return flags for the call STMT. */
>> >> >