[PATCH][RFC] Avoid excessive BLOCK associations for locations

Michael Matz matz@suse.de
Mon Jan 28 15:01:00 GMT 2013


On Mon, 28 Jan 2013, Richard Biener wrote:

> What's the point of switching to the outermost scope for unknown-BLOCK
> locations?

It's the most sensical block for code which isn't otherwise associated 
with a BLOCK.  But the latter Shouldn't Happen, because conceptually all 
code runs in some (perhaps artificial) lookup context.  So, it's actually 
not the inliner which should fixup stuff here, but rather ...

> If we have a non-UNKNOWN_LOCATION, would a NULL BLOCK not be an error 
> anyway?

... whatever is producing such non-BLOCK code snippets.  But see below.

> Isn't inheriting the currently active scope much more useful (it 
> definitely is for UNKNOWN_LOCATIONs)?

And yes, the most likely useful block for such code will be the "currently 
active" block.  This is true only before code transformations of course; 
while optimizing you have the same problems like with locations, i.e. how 
to "merge" multiple different BLOCKs into one sensible.

Now, as an implementation optimization (to not bloat the location/block 
sets perhaps) you can define block==NULL <--> block==outermost-scope, and 
in case you do so, it's indeed the inliner that needs to map NULL blocks 
to the mapped outermost scope of the inlined function.  I would guess that 
this is what historically was done, and when this optimization is still 
employed your patch is wrong.  IMHO this optimization should be used.


More information about the Gcc-patches mailing list