[AArch64] Possible incorrect use of EVT::getVectorNumElements()

[alexey-bataev]

https://godbolt.org/z/nar8W6vTb

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-unknown-linux-gnu"

define <vscale x 4 x float> @test(<vscale x 4 x float> %0) #0 {
iter.check122:
  %1 = frem <vscale x 4 x float> %0, zeroinitializer
  ret <vscale x 4 x float> %1
}

attributes #0 = { "target-cpu"="neoverse-v2" "target-features"="+sve" }

llc -disable-symbolication < reduced.ll
LLVM ERROR: Possible incorrect use of EVT::getVectorNumElements() for scalable vector. Scalable flag may be dropped, use EVT::getVectorElementCount() instead

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Alexey Bataev (alexey-bataev)

Details

https://godbolt.org/z/YT9n9h45c

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-unknown-linux-gnu"

define &lt;vscale x 4 x float&gt; @<!-- -->test(&lt;vscale x 4 x float&gt; %0) #<!-- -->0 {
iter.check122:
  %1 = frem &lt;vscale x 4 x float&gt; %0, zeroinitializer
  ret &lt;vscale x 4 x float&gt; %1
}

attributes #<!-- -->0 = { "target-cpu"="neoverse-v2" }

llc -disable-symbolication < reduced.ll
LLVM ERROR: Possible incorrect use of EVT::getVectorNumElements() for scalable vector. Scalable flag may be dropped, use EVT::getVectorElementCount() instead

[alexey-bataev]

@davemgreen @paulwalker-arm

[davemgreen]

Hi - My understanding is that

• There is no native frem operation we can use for SVE.
• The cost should prevent them from being created for autovec.
• There was a recent issue with -veclib and LTO that was fixed in [LTO][Veclib] Fix vector library handling with LTO #170638.
• There was an ExpandFpPass added recently in [AMDGPU] Implement IR expansion for frem instruction #130988, which we could use for this nowadays.

[alexey-bataev]

There was a recent issue with -veclib and LTO that was fixed in #170638.

Hmm, we see that it is generated with -fveclib=ArmPL in flang (no LTO). Will double check

[alexey-bataev]

Here is the reproducer, which generates scalable vector frem:
https://godbolt.org/z/fGWjbTThf

[davemgreen]

My understanding is that should be OK so long as it is using -vector-library. Providing that -vector-library=ArmPL is used at the codegen stage it should be able to convert the frem into a library call. https://godbolt.org/z/WWvaxeef5

Is there something similar to #170638 needed, where the TargetLibraryInfoImpl is not picking up the VecLib where it should be?

[alexey-bataev]

My understanding is that should be OK so long as it is using -vector-library. Providing that -vector-library=ArmPL is used at the codegen stage it should be able to convert the frem into a library call. https://godbolt.org/z/WWvaxeef5

Is there something similar to #170638 needed, where the TargetLibraryInfoImpl is not picking up the VecLib where it should be?

Yes, I assume flang does not propagate vector library to the target machine correctly. It make LV think that scalable frem is valid, but the codegen is not aware, that frem should be lowered as a math function call. It causes a crash

[alexey-bataev]

https://godbolt.org/z/Gehsd4zfe