https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83883
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-01-17
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Ever confirmed|0 |1
--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
Thanks David!
Idiot moment on my end. There's two functions and DSE is happening in each.
It happens early enough that inlining hasn't occurred. ANd yes, this is
clearly a callee copy thing.
On x86_64 constraint_expr_equal_p looks like:
<bb 2> :
_1 = BIT_FIELD_REF <x, 64, 0>;
_3 = BIT_FIELD_REF <y, 64, 0>;
if (_1 == _3)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
[ ... ]
Whereas on hppa it looks like:
<bb 2> :
x.3 = x;
SR.6_11 = MEM[(struct constraint_expr *)&x];
SR.7_12 = MEM[(struct constraint_expr *)&x + 4B];
SR.8_14 = MEM[(struct constraint_expr *)&x + 8B];
y.4 = y;
SR.9_15 = MEM[(struct constraint_expr *)&y];
SR.10_16 = MEM[(struct constraint_expr *)&y + 4B];
SR.11_17 = MEM[(struct constraint_expr *)&y + 8B];
if (SR.6_11 == SR.9_15)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
And DSE will remove the x.3 = and y.4 = assignments.
While we don't have a dejagnu thingie to test for callee copy in the target, I
think we can tighten the test to avoid the hit in the first function which we
don't actually care about, but still capture the hit in the second function.
Given it's just a testsuite tweak I think we ought to go ahead and do that even
though we're in stage4 -- regardless of how the HPPA linux port has been
tweaked to avoid the problem.
