preserve more debug stmts in gimple jump threading

[Alexandre Oliva]

On May 15, 2019, Richard Biener <richard.guenther@gmail.com> wrote:

> On Wed, May 15, 2019 at 10:20 AM Alexandre Oliva <aoliva@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