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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> The other thing is:
> 
> -ftree-bit-ccp
> Visiting statement:
> _4 = _3 & 1;
> which is likely CONSTANT
> Applying pattern match.pd:1641, gimple-match.c:23146
> Lattice value changed to CONSTANT 0x0 (0x1).  Adding SSA edges to worklist.
> marking stmt to be not simulated again
> 
> vs
> 
> -fno-tree-bit-ccp
> _4 = _3 & 1;
> which is likely CONSTANT
> Applying pattern match.pd:1641, gimple-match.c:23146
> Lattice value changed to VARYING.  Adding SSA edges to worklist.
> 
> In the first case we mark the stmt as not be simulated again while in the
> second case we didn't.

VARYING are always 'not simulated again', the dumping is for an optimization
when all uses in a stmt will never be simulated again.  So the only difference
is the folding where there are constraints which folding results we may
put into the lattice that are not satisfied here and that we do not fold
likely VARYING statements (all the "likely" stuff is compile-time optimization,
eventually premature).  So I don't really see any CCP issue here.  It's just
that without bit-CCP we get

@@ -365,7 +365,7 @@
   f.4_21 = (unsigned short) _5;
   _23 = f.4_21 * 3;
   _24 = (short int) _23;
-  if (_24 == 0)
+  if (_5 == 0)
     goto <bb 6>; [INV]

the real issue is IMHO that forwprop doesn't get to it

@@ -23,13 +23,7 @@

 gimple_simplified to _14 = a.1_2 & 1;
 _4 = (short int) _14;
-gimple_simplified to f_18 = _5;
-Removing dead stmt _7 = _24;
-
-Removing dead stmt _25 = _24;
-
-Removing dead stmt f_18 = _5;
-
+gimple_simplified to if (_5 == 0)

we don't get

/* For integral types with undefined overflow fold
   x * C1 == C2 into x == C2 / C1 or false.
   If overflow wraps and C1 is odd, simplify to x == C2 / C1 in the ring
   Z / 2^n Z.  */
(for cmp (eq ne)
 (simplify
  (cmp (mult @0 INTEGER_CST@1) INTEGER_CST@2)

applied here.  We do get the fold_sign_changed_comparison pattern applied
though, but only from combine_cond_expr_cond and there we do not apply
it because of the single-use restriction and the propagation phase
of forwprop delaying stmt removal confusing that.  The same issue
prevents the GIMPLE variant from applying since it has

/* From fold_sign_changed_comparison and fold_widened_comparison.
   FIXME: the lack of symmetry is disturbing.  */
(for cmp (simple_comparison)
 (simplify
  (cmp (convert@0 @00) (convert?@1 @10))
...
       && single_use (@0))

Reply via email to