Hi, 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. Ciao, Michael.
