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. > 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. 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. -- 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
