Re: [PATCH] Support threading of just the exit edge

[Jeff Law <jeffreyalaw@gmail.com>]

On 8/12/2022 10:03 AM, Aldy Hernandez wrote:
> On Fri, Aug 12, 2022 at 2:01 PM Richard Biener <rguenther@suse.de> wrote:
>> This started with noticing we add ENTRY_BLOCK to our threads
>> just for the sake of simplifying the conditional at the end of
>> the first block in a function.  That's not really threading
>> anything but it ends up duplicating the entry block, and
>> re-writing the result instead of statically fold the jump.
> Hmmm, but threading 2 blocks is not really threading at all??  Unless
> I'm misunderstanding something, this was even documented in the
> backwards threader:
>
> [snip]
>       That's not really a jump threading opportunity, but instead is
>       simple cprop & simplification.  We could handle it here if we
>       wanted by wiring up all the incoming edges.  If we run this
>       early in IPA, that might be worth doing.   For now we just
>       reject that case.  */
>    if (m_path.length () <= 1)
>        return false;
My recollection is that code was supposed to filter out the case where 
the threading path is just a definition block and a use block where the 
definition block dominated the use block.    For that case, threading 
isn't really needed as we can just use const/copy propagation to 
propagate the value from the def to the use which should in turn allow 
the use (the conditional branch) to be simplified away -- all without 
the block copying and associated CFG updates.

What doesn't make sense to me today is how do we know there's a 
dominator relationship between the two blocks?



Jeff