[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> On Wed, Oct 13, 2021, 11:37 pinskia at gcc dot gnu.org <
> gcc-bugzilla@gcc.gnu.org> wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
> >
> > --- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > Because:
> >   if (d_11 > 1)
> >     goto <bb 5>; [59.00%]
> >   else
> >     goto <bb 4>; [41.00%]
> >
> >   <bb 4> [local count: 391808389]:
> >
> >   <bb 5> [local count: 955630225]:
> >   # iftmp.1_6 = PHI <0(3), 2(4)>
> >
> > If the phi node was removed, the original al condition for d_11 > 1 would
> > be
> > remove.
> >
> 
> As the IL stands, the 3->5 edge has relevant range information.  If the IL
> should be different at this point, there is no way the threader can know
> this.

Note that I'm not against a cleanup pass running before as you suggested, or
perhaps whomever made the PHI redundant could also clean up the PHI itself. 
I'm just merely saying that the threader is working as expected with the IL at
hand.

Also, if we did have cleaner IL, we could probably tweak the threader to elide
the call to foo() earlier.  That is, without having to resort to help from the
RTL optimizers.

In this testcase we could probably divine that the combination of the
truncating cast and the bitwise AND is showing that a.4_2 can't have both the
lower bits set and cleared at the same time.  I'm not sure it's worth tweaking
the path solver for this, but it's definitely worth exploring.

As usual, thanks for narrowing all these bug reports.  It makes a big
difference, and your presence during bug hunting season is always a big plus.