On 11/24/18 11:29 AM, Christophe Lyon wrote:

> On Thu, 22 Nov 2018 at 18:30, Vladimir Makarov <vmakarov@redhat.com> 
> wrote:
>> 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 was committed as rev. 260385.
>>
> Hi,
>
> This patch introduced at least several ICEs on arm targets:
> on arm-none-linux-gnueabi --with-cpu=cortex-a9:
<snip>
> There are other regressions on the same targets, but not ICEs.
> I can report them later.
>
> Thanks,
>
> Christophe

Hi Christophe and Vladimir,

Here are the regressions seen on arm-none-linux-gnueabihf and arm-none-eabi.

FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times 
ldrh\\tr[0-9]+ 2
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times 
vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times 
vmov\\.f16\\ts[0-9]+, r[0-9]+ 2
FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler 
vmov(\\.f16)?\\tr[0-9]+, s[0-9]+
FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler vmov(\\.f16)?\\ts0, 
r[0-9]+
FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\tr[0-9]+, 
s[0-2] 2
FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\ts0, 
r[0-9]+ 2

I didn't see a bug report for these, so I will open one.

It is not clear if the test cases should be adjusted because of your 
patch or if they are failing because of incorrect codegen. Attached is 
the code generated for armv8_2-fp16-move-1.c (one of the test files 
failing) with and without your patch.

Full command line used to compile and test armv8_2-fp16-move-1.c:

bin/gcc armv8_2-fp16-move-1.c -fno-diagnostics-show-caret 
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 
-mfpu=fp-armv8 -march=armv8.2-a+fp16 -mfloat-abi=hard -ffat-lto-objects 
-fno-ident -S -o armv8_2-fp16-move-1.s.