Re: LRA patch for PR87718

[Uros Bizjak <ubizjak at gmail dot com>]

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.