[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:05f98310b54da95e468d799f4a910174320cccbb

commit r14-4588-g05f98310b54da95e468d799f4a910174320cccbb
Author: Richard Biener 
Date:   Thu Oct 12 09:09:46 2023 +0200

tree-optimization/111764 - wrong reduction vectorization

The following removes a misguided attempt to allow x + x in a reduction
path, also allowing x * x which isn't valid.  x + x actually never
arrives this way but instead is canonicalized to 2 * x.  This makes
reduction path handling consistent with how we handle the single-stmt
reduction case.

PR tree-optimization/111764
* tree-vect-loop.cc (check_reduction_path): Remove the attempt
to allow x + x via special-casing of assigns.

* gcc.dg/vect/pr111764.c: New testcase.

[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-12 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

--- Comment #6 from Richard Biener  ---
Shorter testcase, fails at -O2 -ftree-vectorize

short b;
int main()
{
  b = 2;
  for (int a = 1; a <= 9; a++)
b = b * b;
  if (b != 0)
__builtin_abort ();
}

it "works" with unsigned short b because the non-path reduction detection
doesn't allow two uses of 'b':

t.c:5:21: note:   Analyze phi: b_lsm.6_2 = PHI 
t.c:5:21: missed:   reduction used in loop.
t.c:5:21: missed:   Unknown def-use cycle pattern.

but the path based reduction detection has

/* We want to allow x + x but not x < 1 ? x : 2.  */
if (is_gimple_assign (op_use_stmt)
&& gimple_assign_rhs_code (op_use_stmt) == COND_EXPR)

which also allows x * x to slip through.  Even when fixing the earlier
issue of the initial value we end up with

  vect_b.13_27 = { 2, 1, 1, 1, 1, 1, 1, 1 };
  vect_powmult_5.14_28 = vect_b.13_27 * vect_b.13_27;

allowing x + x is only OK because it's 2 * x and we will actually never
see it as x + x.

[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-12 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

--- Comment #5 from Richard Biener  ---
Hmm, that's not enough, the issue is this is detected as reduction at all.

[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-11 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

--- Comment #4 from Richard Biener  ---
  /* Try to simplify the vector initialization by applying an
 adjustment after the reduction has been performed.  */
  if (!reduc_info->reused_accumulator
  && STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def
  && !operand_equal_p (neutral_op, initial_def))
{
  STMT_VINFO_REDUC_EPILOGUE_ADJUSTMENT (reduc_info)
= initial_def;
  initial_def = neutral_op;
}

maybe just allow PLUS/MINUS_EXPR here.  Maybe it's all premature ...

[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-11 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
OK, so the vectorizer transforms

 b = 2;
 for (;;)
   b = b * b;

to

 b = 1;
 for (;;)
   b = b * b;
 b *= 2;

which is obviously wrong(TM).

[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Note r11-5965-g04bff1bbfc1 just exposed the issue, you can reproduce the
> issue before that with `-fno-vector-cost-model` added and it worked with
> that option in GCC 9.5.0 but was broken in GCC 10.1.0.

Sorry I mean `-fno-vect-cost-model`.

[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

2023-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-10
   Target Milestone|--- |11.5
Summary|Wrong code at -O3 on|[11/12/13/14 Regression]
   |x86_64-linux-gnu since  |Wrong code at -O3 on
   |r11-5965-g04bff1bbfc1   |x86_64-linux-gnu
 Ever confirmed|0   |1
  Known to work||10.5.0
   Keywords||needs-bisection
  Known to fail||11.1.0, 12.1.0, 13.1.0

--- Comment #1 from Andrew Pinski  ---
Note r11-5965-g04bff1bbfc1 just exposed the issue, you can reproduce the issue
before that with `-fno-vector-cost-model` added and it worked with that option
in GCC 9.5.0 but was broken in GCC 10.1.0.


Confirmed.