On 8/12/2022 10:03 AM, Aldy Hernandez wrote:
On Fri, Aug 12, 2022 at 2:01 PM Richard Biener <rguent...@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
