[AArch64][SME] Use `fmov` instead of NEON `movi` for FP value.

[sdesmalen]

Summary

NEON movi is not valid in Streaming SVE mode, so use an fmov
instruction instead for zero-initializing a FP value.

[hassnaa-arm]

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp

1333

conceptually what is the difference between hasNEON and isNeonAvailable() ?
I saw the implementation of isNeonAvailable which is the opposite of hasNEON or the opposite of streaming mode.
But I don't understand how the implementation of isNeonAvailable() represents its name.

1333

What is the difference between this class 'AArch64AsmPrinter' and tblgen files ?
Another thing, I see that in the tblgen files there are some conditions about generating code compatible with specific features, so what is the difference between handling the compatible generated code in the tblgen files and handling it here ?

llvm/test/CodeGen/AArch64/sve-streaming-mode-test-register-mov.ll

36

while the initialised vector is double, why is this mov instead of fmov ?

[sdesmalen]

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp

1333

conceptually what is the difference between hasNEON and isNeonAvailable() ?

isNeonAvailable() used to be !forceStreamingCompatibleSVE(), see ec6af93d0249d03a5babd547e072e4de3a2b5e48.
Basically, if the function is a streaming function, or a streaming-compatible function, then Neon is not available.

I could have named it isNeonAvailableAtRuntime, but isNeonAvailable was shorter.

hasNEON is more to do with what target features we compile for. So while we target a core that has NEON instructions, in the given _runtime_ mode we may not be able to use them.

What is the difference between this class 'AArch64AsmPrinter' and tblgen files ?

AsmPrinter emits a the *actual* instruction for the given MachineInstr, which is an intermediate representation of either a pseudo or a real instruction. In this case, FMOVS0 is a pseudo node that gets expanded here to the appropriate instruction.

Another thing, I see that in the tblgen files there are some conditions about generating code compatible with specific features, so what is the difference between handling the compatible generated code in the tblgen files and handling it here ?

In TableGen we define the instructions (with their encodings) and have patterns to map to those instructions, or to a pseudo node. I'm not entirely sure why they took the approach here to map to a pseudo node, rather than directly map to the appropriate instruction using a pattern. Perhaps the simpler pseudo node has some benefits, but I don't see that much code that uses it's simpler representation. There is code in InstrInfo to say that an FMOV[HSD]0 is cheap and also a change in the scheduler specific to FMOV[HSD]0.

The purpose of this patch is to fix the issue, so I didn't touch the previous design choices on how this is represented.

[hassnaa-arm]

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp

1333

Thanks for the explanation :)

[sdesmalen]

llvm/test/CodeGen/AArch64/sve-streaming-mode-test-register-mov.ll

36

FMOV (vector, immediate) is not available in streaming SVE mode, so we can't use it. Instead we use the SVE mov instruction instead.

[hassnaa-arm]

LGTM. Thanks for the clarification.

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp

void AArch64AsmPrinter::LowerFAULTING_OP(const MachineInstr &FaultingMI) {
 
   OutStreamer->AddComment("on-fault: " + HandlerLabel->getName());
   OutStreamer->emitInstruction(MI, getSubtargetInfo());
 }
 
 void AArch64AsmPrinter::emitFMov0(const MachineInstr &MI) {
   Register DestReg = MI.getOperand(0).getReg();
   if (STI->hasZeroCycleZeroingFP() && !STI->hasZeroCycleZeroingFPWorkaround() &&
-      STI->hasNEON()) {
+      STI->isNeonAvailable()) {
     // Convert H/S register to corresponding D register
     if (AArch64::H0 <= DestReg && DestReg <= AArch64::H31)
       DestReg = AArch64::D0 + (DestReg - AArch64::H0);
     else if (AArch64::S0 <= DestReg && DestReg <= AArch64::S31)
       DestReg = AArch64::D0 + (DestReg - AArch64::S0);
     else
       assert(AArch64::D0 <= DestReg && DestReg <= AArch64::D31);
 

llvm/test/CodeGen/AArch64/sve-streaming-mode-fixed-length-stores.ll

 ; CHECK-NEXT:    ret
   store <1 x i64> zeroinitializer, ptr %a
   ret void
 }
 
 define void @store_v1f64(ptr %a) #0 {
 ; CHECK-LABEL: store_v1f64:
 ; CHECK:       // %bb.0:
-; CHECK-NEXT:    movi d0, #0000000000000000
+; CHECK-NEXT:    fmov d0, xzr
 ; CHECK-NEXT:    str d0, [x0]
 ; CHECK-NEXT:    ret
   store <1 x double> zeroinitializer, ptr %a
   ret void
 }
 
 define void @store_v2i64(ptr %a) #0 {
 ; CHECK-LABEL: store_v2i64:

llvm/test/CodeGen/AArch64/sve-streaming-mode-test-register-mov.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -force-streaming-compatible-sve  < %s | FileCheck %s
 
 target triple = "aarch64-unknown-linux-gnu"
 
 ; A NEON Q-register mov is not valid in streaming mode, but an SVE Z-register mov is.
 define fp128 @test_streaming_compatible_register_mov(fp128 %q0, fp128 %q1) #0 {
 ; CHECK-LABEL: test_streaming_compatible_register_mov:
 ; CHECK:       // %bb.0:
 ; CHECK-NEXT:    mov z0.d, z1.d
 ; CHECK-NEXT:    ret
   ret fp128 %q1
 }
 
+; Test that `movi` isn't used (invalid in streaming mode), but fmov or SVE mov instead.
+define double @fp_zero_constant() #0 {
+; CHECK-LABEL: fp_zero_constant:
+; CHECK:       // %bb.0:
+; CHECK-NEXT:    fmov d0, xzr
+; CHECK-NEXT:    ret
+  ret double 0.0
+}
+
+define <2 x i64> @fixed_vec_zero_constant() #0 {
+; CHECK-LABEL: fixed_vec_zero_constant:
+; CHECK:       // %bb.0:
+; CHECK-NEXT:    mov z0.d, #0 // =0x0
+; CHECK-NEXT:    // kill: def $q0 killed $q0 killed $z0
+; CHECK-NEXT:    ret
+  ret <2 x i64> zeroinitializer
+}
+
+define <2 x double> @fixed_vec_fp_zero_constant() #0 {
+; CHECK-LABEL: fixed_vec_fp_zero_constant:
+; CHECK:       // %bb.0:
+; CHECK-NEXT:    mov z0.d, #0 // =0x0
+; CHECK-NEXT:    // kill: def $q0 killed $q0 killed $z0
+; CHECK-NEXT:    ret
+  ret <2 x double> <double 0.0, double 0.0>
+}
+
 attributes #0 = { "target-features"="+sve" }