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.
