Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> 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 symtab
> 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
> representation.
> 
> 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 relatively convoluted
places within frontend before cgraph node is assigned to them (I tried that few years
back).
I think we may be on better track moving DECL_ASSEMBLER_NAME that is calculated later,
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
in there.

Getting struct function out of frontend busyness would be nice indeed, too, but probably
should be independent of Martin's work here.

Honza
> 
> Thanks,
> Richard.
> 
> > Thanks,
> >
> > Martin
> >
> >>
> >> > +       }
> >> >      }
> >> > +
> >> > +  return ret;
> >> >  }
> >> >
> >> >  /* Detects return flags for the call STMT.  */
> >> >