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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  C testcase:

int my_max(int a, int b){ return (a<b)?b:a; }

int bar(int *vec)
{
  int sup = 0;
  for (int i = 0; i < 1024; ++i)
    sup = my_max(sup,my_max(vec[2*i],vec[2*i+1]));
  return sup;
}

int foo(int *vec)
{
  int sup = 0;
  for (int i = 0; i < 1024; ++i)
    sup = my_max(my_max(sup, vec[2*i]),vec[2*i+1]);
  return sup;
}

with -O3 we get both "slow", with -O3 -fno-tree-reassoc 'foo' remains fast.

I think reassoc works backwards here, it makes classical reduction
discovery possible but wrecks with reduction chains.

Reply via email to