On Wed, May 15, 2019 at 11:03 PM Alexandre Oliva <aol...@redhat.com> wrote: > > On May 15, 2019, Richard Biener <richard.guent...@gmail.com> wrote: > > > On Wed, May 15, 2019 at 10:20 AM Alexandre Oliva <aol...@redhat.com> wrote: > >> > >> Gimple jump threading does not duplicate forwarder blocks that might > >> be present before or after the copied block. > > > Empty forwarder blocks I presume? > > Empty except for debug stmts and possibly a final conditional jump that, > in the threading path, becomes unconditional. > > > I wonder if not copying empty forwarders is premature optimization > > in that (hopefully) CFG cleanup is run after jump threading anyways? > > I don't think it's so much of an optimization as it is an extension. > The code as it is can only really handle copying the initial block and > another subsequent block. Threading through other "empty" blocks > didsn't require as significant changes as copying them would have. > > If we were to change that, then we'd be extending jump threading to > actually copy multiple blocks, empty or not. Not necessarily a bad > thing, but there are comments in the code suggesting that hasn't really > been tried.
Oh, I see - I thought we've extended the code to copy an arbitrary length path by now ... > > If we'd copy the blocks the patch would be moot? > > Yes, but with a caveat. > > It's true that cfgcleanup would pretty much end up having the same or > similar effect, consolidating debug stmts from empty blocks into > successor or predecessor if possible and dropping them otherwise. > > What it would not do is to consolidate binds from the now-split paths > into the confluence, like propagate_threaded_block_debug_into does. The > proposed patch does not change that, and it shouldn't: the confluence > binds stand on their own (*), very much like the binds we add after PHI > nodes when entering SSA. Ah, I missed that, so yes, it looks more powerful. > That reduces the loss when we don't have a place to hold the debug > stmts, and it helps bind resolution in var-tracking even when the > incoming paths seem to have diverged in where they hold a variable, at > least when the binds don't end up being reset for this very reason even > when var-tracking dataflow could have figured out a common location > among the incoming blocks. > > (*) though memory references in them might become wrong if they're > before the second block and the second block changes the memory > locations, it occurs to me now, without actually going back and checking > whether the consolidation pays any attention to that. > > We shouldn't assume that just because we're now copying all intermediate > blocks, debug info and all, the confluence binds cease to be useful. > Rather, we should probably consider introducing them in other passes > that split paths and introduce new confluences. Indeed. Richard. > -- > Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo > Be the change, be Free! FSF Latin America board member > GNU Toolchain Engineer Free Software Evangelist > Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
