[AArch64] Assertion `!(SetNZCV && (NumPredicateVectors || NumDataVectors)) && "SetNZCV not supported with SVE vectors"' failed at -O1/O2/O3

[XChy]

Reduced testcase:

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32"
target triple = "aarch64-buildroot-linux-gnu"

define void @i(ptr %ad, ptr %0) #0 {
entry:
  %aj = alloca i32, align 4
  callbr void asm sideeffect "", "!i,!i"()
          to label %asm.fallthrough [label %ah.preheader.preheader, label %ah.preheader.preheader]

ah.preheader.preheader:                           ; preds = %entry, %entry
  %conv = xor i8 0, 1
  br label %ah

asm.fallthrough:                                  ; preds = %entry
  unreachable

ah:                                               ; preds = %asm.fallthrough2, %asm.fallthrough2, %ah, %ah.preheader.preheader
  %af.2 = phi <8 x i64> [ zeroinitializer, %asm.fallthrough2 ], [ <i64 4056814946905, i64 0, i64 0, i64 0, i64 0, i64 0, i64 0, i64 0>, %ah.preheader.preheader ], [ zeroinitializer, %asm.fallthrough2 ], [ zeroinitializer, %ah ]
  %vecext = extractelement <8 x i64> %af.2, i64 0
  store i64 %vecext, ptr %ad, align 8
  call void asm sideeffect "", "~{v11}"()
  callbr void asm sideeffect "", "!i"()
          to label %asm.fallthrough2 [label %ah]

asm.fallthrough2:                                 ; preds = %ah
  %call = call i32 @g()
  store i8 %conv, ptr %0, align 1
  %cmp = icmp ne ptr %aj, null
  %conv3 = zext i1 %cmp to i32
  store i32 %conv3, ptr %ad, align 4
  callbr void asm sideeffect "", "!i"()
          to label %ah [label %ah]
}

declare i32 @g(...)

attributes #0 = { "frame-pointer"="non-leaf" "target-features"="+sve" }

Godbolt link: https://godbolt.org/z/avYszEcEG
This testcase is reduced from a well-defined C program.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Hongyu Chen (XChy)

Reduced testcase: ```llvm target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32" target triple = "aarch64-buildroot-linux-gnu"

define void @i(ptr %ad, ptr %0) #0 {
entry:
%aj = alloca i32, align 4
callbr void asm sideeffect "", "!i,!i"()
to label %asm.fallthrough [label %ah.preheader.preheader, label %ah.preheader.preheader]

ah.preheader.preheader: ; preds = %entry, %entry
%conv = xor i8 0, 1
br label %ah

asm.fallthrough: ; preds = %entry
unreachable

ah: ; preds = %asm.fallthrough2, %asm.fallthrough2, %ah, %ah.preheader.preheader
%af.2 = phi <8 x i64> [ zeroinitializer, %asm.fallthrough2 ], [ <i64 4056814946905, i64 0, i64 0, i64 0, i64 0, i64 0, i64 0, i64 0>, %ah.preheader.preheader ], [ zeroinitializer, %asm.fallthrough2 ], [ zeroinitializer, %ah ]
%vecext = extractelement <8 x i64> %af.2, i64 0
store i64 %vecext, ptr %ad, align 8
call void asm sideeffect "", "~{v11}"()
callbr void asm sideeffect "", "!i"()
to label %asm.fallthrough2 [label %ah]

asm.fallthrough2: ; preds = %ah
%call = call i32 @g()
store i8 %conv, ptr %0, align 1
%cmp = icmp ne ptr %aj, null
%conv3 = zext i1 %cmp to i32
store i32 %conv3, ptr %ad, align 4
callbr void asm sideeffect "", "!i"()
to label %ah [label %ah]
}

declare i32 @g(...)

attributes #0 = { "frame-pointer"="non-leaf" "target-features"="+sve" }

Godbolt link: https://godbolt.org/z/avYszEcEG
This testcase is reduced from a well-defined C program.
</details>

[XChy]

MIR test: https://godbolt.org/z/qodq8bPPr

[sdesmalen-arm]

I'm actually surprised that the %cmp = icmp ne ptr %aj, null hasn't been optimised away, because the alloca allocates the object in the default address space where I believe the returned pointer can never be null on AArch64. Some discussion about this I could find are in: https://reviews.llvm.org/D40670 and https://lists.llvm.org/pipermail/llvm-dev/2017-December/119738.html.

That thread explains this cannot be assumed for all cases, but for AArch64 with the default address space I think we could.
For example, when I create an example from C++ clang adds nonnull to the address of the alloca on its use (https://godbolt.org/z/n7zWYT1G4) so this assumption is already made in some other places.

@davemgreen @arsenm do you know if some work has been done in this area or if anything is missing for AArch64?

[arsenm]

It does fold out with -passses=instsimplify

[davemgreen]

We have in the past had (ir) passes in the backend that run instsimplify, usually as a byproduct of what they are doing. I don't think any do at the moment though, they can end up making tests for edge-cases of SDAG harder to write.

[sdesmalen-arm]

Yeah, I was mostly just figuring out if there was an opportunity to optimise this case further if such an optimisation didn't exist already, because I expected the original reproducer to have come from a pipeline that had been run at >= O1. If this is already optimised at the IR level though, that's good enough.