On May 22, 2014 5:24:33 PM CEST, Jan Hubicka <hubi...@ucw.cz> 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 >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).
Well, just call cgraph create node from struct Funktion allocation. Richard. >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. */ >> >> >
