On Thu, Aug 16, 2012 at 8:40 AM, Michael Matz <m...@suse.de> wrote: > 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.
I like this approach, particularly since it would be used in contexts where there is no simpler scheme. I'm not crazy about overloading unused fields, but it's fine if we wrap it around a special accessor. I suppose we could also make ENTRY/EXIT be a base class for basic_block and use a real field (but that can wait). There are other pieces of data that are "global" but context-dependent. I wonder if it wouldn't make sense to encapsulate them in some class that is controlled by the pass manager and gets updated as it moves from function to function (it would contain things like cfun, current_function_decl, etc). Diego.
