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.