Hello!
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
>
> The patch adds a special treatment for moves with a hard register in
> register cost and class
> calculation.
>
> The patch was bootstrapped and tested on x86-64 and ppc64.
>
> I found two testsuite regressions because of the patch. The expected
> generated code for
> PR82361 test is too specific. GCC with the patch generates the same quality
> code but with a
> different hard register on x86-64. So I just changed the test for PR82361.
> Another test is for
> ppc64. I think the expected generated code for this test is wrong. I'll
> submit a changed test
> for a discussion later. Although I spent much time on the solution and I
> think it is the right one,
> the patch is in very sensitive area of RA and may affect expected code
> generation for many
> targets. I am ready to work on the new regressions as soon as they are found.
The patch regressed:
FAIL: gcc.target/i386/pr22076.c scan-assembler-not movl
FAIL: gcc.target/i386/pr81563.c scan-assembler-times movl[\\t
]*-4\\(%ebp\\),[\\t ]*%edi 1
FAIL: gcc.target/i386/pr81563.c scan-assembler-times movl[\\t
]*-8\\(%ebp\\),[\\t ]*%esi 1
on 32 bit x86 target.
The PR22076 moves a value from mm0 via integer register to a volatile location:
movq .LC1, %mm0
paddb .LC0, %mm0
movq %mm0, 16(%esp)
movl 16(%esp), %eax
movl 20(%esp), %edx
movl %eax, (%esp)
movl %edx, 4(%esp)
movq (%esp), %mm0
addl $28, %esp
where before the patch we had:
movq .LC1, %mm0
paddb .LC0, %mm0
movq %mm0, 8(%esp)
movq 8(%esp), %mm0
addl $20, %esp
The PR81563 looks like a testsuite issue, where the compiler now
allocates call-clobbered register for a value that lives across the
call.
Uros.
