[x86] Tweak testcases for PR82361
authorRichard Sandiford <richard.sandiford@arm.com>
Wed, 18 Sep 2019 07:38:32 +0000 (07:38 +0000)
committerRichard Sandiford <rsandifo@gcc.gnu.org>
Wed, 18 Sep 2019 07:38:32 +0000 (07:38 +0000)
commitad4644f378fe2f731cd987a4aff14b935f530b88
treee1ab6bf98f498255409c3b8f4e0d0b004e09dc63
parent6a6341917f9e6d8cf500c24883e543caf3b6af8b
[x86] Tweak testcases for PR82361

gcc/testsuite/gcc.target/i386/pr82361-[12].c check whether we
can optimise away a 32-to-64-bit zero extension of a 32-bit
division or modulus result.  Currently this fails for the modulus
part of f1 and f2 in pr82361-1.c:

/* FIXME: We are still not able to optimize the modulo in f1/f2, only manage
   one.  */
/* { dg-final { scan-assembler-times "movl\t%edx" 2 } } */

pr82361-2.c instead expects no failures:

/* Ditto %edx to %rdx zero extensions.  */
/* { dg-final { scan-assembler-not "movl\t%edx, %edx" } } */

But we actually get the same zero-extensions for f1 and f2 in pr82361-2.c.
The reason they don't trigger a failure is that the RA allocates the
asm input for "d" to %rdi rather than %rdx, so we have:

movl %rdx, %rdi

instead of:

movl %rdx, %rdx

For the tests to work as expected, I think they have to force "c" and
"d" to be %rax and %rdx respectively.  We then see the same failure in
pr82361-2.c as for pr82361-1.c (but doubled, due to the 8-bit division
path).

2019-09-18  Richard Sandiford  <richard.sandiford@arm.com>

gcc/testsuite/
* gcc.target/i386/pr82361-1.c (f1, f2, f3, f4, f5, f6): Force
"c" to be in %rax and "d" to be in %rdx.
* gcc.target/i386/pr82361-2.c: Expect 4 instances of "movl\t%edx".

From-SVN: r275836
gcc/testsuite/ChangeLog
gcc/testsuite/gcc.target/i386/pr82361-1.c
gcc/testsuite/gcc.target/i386/pr82361-2.c