This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function


Hi,

On Thu, 16 Aug 2012, Richard Guenther wrote:

> If dumping a statement needs the containing function then we need to 
> either pass that down, provide a way to get from statement to function, 
> or stop requiring the function.  Making the hash global is choice three 
> (deallocating the hash would be when compilation is finished, in which 
> case you can double-check that it is empty and preserve above checking). 
> Option one is ok as well, option two is probably either unreliable 
> (going from gimple_block to function from function scope - but maybe who 
> cares for dumping?) or expensive (add a pointer from basic_block to 
> struct function).  I'm fine with both option three (would even save a 
> pointer in struct function!) or one.
> 
> Other opinions?

Actually I must say, that none of the above three options appeal to me 
very much, and that the current solution (passing cfun via a global 
variable) is better than any of these:

1) passing it down in arguments: uglifies interface for a very special 
   situation.
3) making the hash global is a layering violation in its own, and for 
   instance would complicate a scheme where the memory for instructions 
   (and their histograms) comes from per-function pools.
2) that's actually the most appealing one from a user interface, i.e. if 
   there's a generic way of mapping gimple -> FUNCTION_DECL.  Certainly 
   not at the cost of an additional pointer in each bb, but there are 
   other schemes that we could use, for instance:
   Every function has an ENTRY and EXIT block.  That one for certain is 
   reachable via going bb->prev_bb until you hit the end.  The entry block 
   doesn't contain much interesting things, so we for instance can reuse, 
   I don't know, the loop_father pointer to actually point to the 
   function_decl containing it.

   Looking up the function from a bb would hence be a fairly expensive 
   operation (walking the block chain), so it requires some care to use 
   it, but I think that's okay.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]