[ARM] Fix test inlineasm-X-allocation.ll

[SjoerdMeijer]

Summary

While working on FileCheck producing better diagnostics in D53710,
I noticed that this test case is broken in a few different ways, and
wanted to check the changes I made (because there are few things I
don't understand here).

The problem was that labels vfp-CHECK and novfp-CHECK where not
checked, so the test wasn't doing anything. Replacing this with just vfp
and novfp revealed a test failure in the novfp case: it was actually
producing vadd.f32 s0, s0, s0 and not using the GPR registers. But I
don't see how we can ever get GPR registers here, thus I don't think
this test makes much sense, and I have just removed it.

[sbaranga]

IIRC the contents of the asm string shouldn't matter here, and we would expect to get an error in the assembler instead when trying to assemble the output (which is fine, since this is a misuse of the X constraint).

However, it seems wrong for the compiler to assign s0 as an operand without having FP registers available.

[SjoerdMeijer]

However, it seems wrong for the compiler to assign s0 as an operand without having FP registers available.

Okay, to be more precise, I don't understand what exactly we are expecting here. Why are we expecting vadd.f32 to work on integer registers? What I mean is that I see -neon is specified, but why in the absense of that do we expect integer registers here. That doesn't make much sense for vadd.f32, isn't it?

[sbaranga]

The initial intent was to make sure that we are forcing the operands to not be VFP registers, so I would have expected to get a vadd.f32 r0, r0, r0. However, since the instruction is invalid it doesn't make a good test (as you observed).

Using a

call void asm sideeffect "// foo $0, $0, $0", "X" (float %f) nounwind

instruction would work just as well for this test and it wouldn't produce an assembler error.

[SjoerdMeijer]

Ah, I finally got it, and many thanks for explaining! I know see too that the mnemonic is totally irrelevant here (I got hugely distracted by vadd.f32).
I've learned something today! :-)

I think I've now tidied up the test case, and it is a bit more sensible.

[SjoerdMeijer]

This time with the correct diff attached; the previous one had the test cases swapped.

[sbaranga]

Thanks, LGTM!

llvm/trunk/test/CodeGen/ARM/inlineasm-X-allocation.ll

-; RUN: llc -mtriple=armv7-none-eabi -mattr=-neon,-vfpv2 %s -o - | FileCheck %s  -check-prefix=novfp
-; RUN: llc -mtriple=armv7-none-eabi -mattr=+neon %s -float-abi=hard -o - | FileCheck %s -check-prefix=vfp
+; RUN: llc -mtriple=armv7-none-eabi -mattr=-neon,-vfp2 %s -o - | FileCheck %s  -check-prefixes=COMMON,NOVFP
+; RUN: llc -mtriple=armv7-none-eabi -mattr=+neon %s -float-abi=hard -o - | FileCheck %s -check-prefixes=COMMON,VFP
 
-; vfp-LABEL: f1
-; vfp-CHECK: vadd.f32 s0, s0, s0
+; The intent here is to test "X", which says that any operand whatsoever is allowed.
+; Using this mechanism, we want to test toggling allocating GPR or SPR registers
+; depending on whether the float registers are available. Thus, the mnemonic is
+; totally irrelevant here, which is why we use FOO and also comment it out using "@"
+; to avoid assembler errors.
 
-; In the novfp case, the compiler is forced to assign a core register.
-; Although this register class can't be used with the vadd.f32 instruction,
-; the compiler behaved as expected since it is allowed to emit anything.
+; Note that this kind of IR can be generated by a function such as:
+;  void f1(float f) {asm volatile ("@FOO $0, $0" : : "X" (f));}
 
-; novfp-LABEL: f1
-; novfp-CHECK: vadd.f32 r0, r0, r0
-
-; This can be generated by a function such as:
-;  void f1(float f) {asm volatile ("add.f32 $0, $0, $0" : : "X" (f));}
-
-define arm_aapcs_vfpcc void @f1(float %f) {
+define arm_aapcs_vfpcc void @func(float %f) {
+; COMMON-LABEL: func
+; NOVFP:        FOO r0, r0
+; VFP:          FOO s0, s0
 entry:
-  call void asm sideeffect "vadd.f32 $0, $0, $0", "X" (float %f) nounwind
+  call void asm sideeffect "@FOO $0, $0", "X" (float %f) nounwind
   ret void
 }