[PATCH][RFC] Avoid excessive BLOCK associations for locations
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
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
... 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