https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69942
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-03-02
CC| |law at redhat dot com
Ever confirmed|0 |1
--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
I'm not sure I follow the logic in c#2.
As we leave the tree optimizers, we have this in the .optimized dump:
<bb 2>:
if (x_3(D) > y_4(D))
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
<bb 4>:
# i_1 = PHI <x_3(D)(2), a_5(D)(3)>
# j_2 = PHI <y_4(D)(2), a_5(D)(3)>
_6 = i_1 * j_2;
return _6;
Which is basically what I'd expect and is consistent with x86-64.
What's awful strange is how the sparc & x86-64 differ in how they coalesce (or
fail to). That ultimately leads to changes in the initial code generation and
changes in what CE1 does.
Before changing the expected output of .ce1 I think we should look more closely
at the coalescing differences between x86-64 and sparc.
The difference is on the sparc, we don't see a conflict between i_1/a_5 and
j_2/a_5. The lack of conflicts changes coalescing and we end up with different
code at expansion time. That ultimately leads to a change in the code seen by
CE and the differences in behavior.
But I think we should look more closely at coalescing before jumping to
changing the expected output from .ce1.
