On Mon, 4 Sep 2017, Uros Bizjak wrote:
> introduced a couple of regressions on x86 (-m32, 32bit) testsuite:
>
> New failures:
> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild)
> FAIL: gcc.target/i386/pr71245-2.c scan-assembler-not movlps
Sorry. I suggest that the tests be XFAIL'ed, the peepholes introduced in the
fix for PR 71245 removed, and the PR reopened (it's a missed-optimization PR).
I can do all of the above if you agree.
I think RTL peepholes are a poor way of fixing the original problem, which
actually exists on all targets with separate int/fp registers. For instance,
trunk (without my patch) still gets a far simpler testcase wrong (-O2, 64-bit):
float f(_Atomic float *p)
{
return *p;
}
f:
movl (%rdi), %eax
movl %eax, -4(%rsp)
movss -4(%rsp), %xmm0
ret
I believe adding more peepholes to handle this, independently in each affected
backend, is hardly appropriate.
The issue is caused by translation of floating-point atomic loads/stores to a
sequence of integer atomic and a VIEW_CONVERT_EXPR on GIMPLE, which in turn
causes the load to be emitted (wrongly) in an integer mode on RTL. I don't
know if GIMPLE atomic builtins can work with floating operands (which IMHO
would be a preferable way), but if not, then special-casing a sequence of
integer atomic mem op and a VCE at expand time might be a cleaner way of
achieving the desired optimization.
Thanks.
Alexander
