[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-07-18 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-07-15 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

--- Comment #10 from Andrew Pinski  ---
Created attachment 58663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58663=edit
Reduced testcase based on suggestion

Reduced testcase based on comment #8.
Notes on it, you need a and b be different types so there is a cast for b to
anchor the range on it inside the if. The input value of a does not matter in
this case as since flag is sets a to 1.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-07-15 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

--- Comment #9 from Andrew Pinski  ---
*** Bug 115925 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-06-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

--- Comment #8 from Richard Biener  ---
ANTIC_IN[6] := { _5 (0005), _16 (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_19} (0017) }
ANTIC_IN[8] := { _5 (0005), _16 (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_17} (0017) }
ANTIC_IN[11] := { _5 (0005), _16 (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_24} (0017) }

merge 8 + 11:
ANTIC_IN[7] := { b.0_1 (0001), _5 (0005), _16 (0014), {bit_not_expr,_16}
(0016), {bit_ior_expr,_5,_17} (0017), {bit_ior_expr,_5,_24} (0017) }

merge 7 + 6:
ANTIC_IN[5] := { b.0_1 (0001), iftmp.2_9 (0008), {nop_expr,iftmp.2_9} (0005),
{bit_not_expr,_5} (0006), {nop_expr,b.0_1} (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_19} (0017), {bit_ior_expr,_5,_17} (0017),
{bit_ior_expr,_5,_24} (0017) 

that's all OK.  Note all exprs have the same value (0017) here.  Then
we PHI-translate to where _5 == 0:
ANTIC_IN[14] := { b.0_1 (0001), {nop_expr,b.0_1} (0014), {bit_not_expr,_16}
(0016) }
which is OK, 0 | .. gets simplified to ~16

Then we PHI-translate to where _5 == 1:
ANTIC_IN[4] := { b.0_1 (0001), {nop_expr,b.0_1} (0014), {bit_not_expr,_16}
(0016), {bit_ior_expr,_17,1} (0027), {bit_ior_expr,_24,1} (0028) }
even that's OK, you see that we simplified just _5 | _19 to 1 (constants
are not tracked in the set, the translated _17 | _5 and _24 | _5 got
different value numbers).

But then:

Found partial redundancy for expression {bit_ior_expr,_5,_19} (0017)
...
Created phi prephitmp_29 = PHI <1(4), _28(14)>
 in block 5 (0017)

see how we figured the redundancy for value 0017 (because _5 | _19
simplified to 1) and we use the same value for the PHI as for all of
the expressions.

That we now keep all PRE exprs didn't save us here.  _19 _is_ the leader
for the expression as we translate it.  The problem is the other
expressions for the same value do not translate the same.

This is probably a longer latent issue since we scrapped resetting
ranges which likely means since RPO VN.  It's always a bit of luck
but I guess since we now track all expressions we have for a value
this got more robust in triggering.  It of course also needs a suitable
simplification to manifest.

I have to think about this.  Simplifying to sth like

  if (flag)
a = 1;
  if (b & 1 == b) // b [0,1]
x = a | b;
  else
x = a | b;
  return x;

should be possible.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-06-16 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

Richard Biener  changed:

   What|Removed |Added

Version|unknown |14.1.1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
I will have a look.  Note PRE expression simplification should _only_ work
based on avails by design.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-06-14 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
hmm,  I think I see what is happening.

So we start with:
  # RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
  _4 = (unsigned charD.20) iftmp.2_8;
  # RANGE [irange] unsigned char [254, +INF] MASK 0x1 VALUE 0xfe
  _5 = ~_4;

  if (_5 != _14)
goto ; [66.00%]
  else
goto ; [34.00%]

bb5:
  # RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
  _17 = ~_14;
  # RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
  _18 = _4 | _17;

...

bb6:
...
  _15 = ~_14;
  _7 = _4 | _15;


So PRE is consolidating _17 and _15 as being the same and using _17 as the
leader.
And when it realizes _4 is 1 on the bb6 and goes to do the simplify, does 1 |
_17 but gets simplified to 1 but `~_14` range in bb6 is not [0,1].

So the issue is PRE is not removing the range from _17 before doing the
simplification while consolidating the two ssa names.

Richi,
  can you look into this further? match is doing exactly what it is being asked
of it but it looks like PRE is messing up due to conditional ranges.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

2024-06-14 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Hmm. disabling:
> 
> /* x | C -> C if we know that x & ~C == 0.  */
> (simplify
>  (bit_ior SSA_NAME@0 INTEGER_CST@1)
>  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
>   && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
>   @1))
> 
> Fixes it.
> 
> So this was caused/exposed by r14-3485-g6df8dcec7196e4 .
> 
> Note that above pattern is hitting during PRE. I have to double check to
> make sure that is correct.

The match pattern is correct what we get through PRE is:
_17 | 1
Where _17's range is [0,1]
so obvious this is just 1.

So either what pre is sending off to match-and-simplify is wrong or the way pre
uses match-and-simplify is wrong. What the match does is correct for what it is
given..