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.