You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Encountering an ICE after removing NEON preference in useSVEForFixedLengthVectors for 128-bit vector register size SVE code generation.
Context:
There's currently a >= 256 vector size restriction in useSVEForFixedLengthVectors (in "llvm/lib/Target/AArch64/AArch64Subtarget.h").
booluseSVEForFixedLengthVectors() const {
// Prefer NEON unless larger SVE registers are available.returnhasSVE() &&getMinSVEVectorSizeInBits() >= 256;
}
As an experiment I've relaxed it in two different ways, by changing the line in question to return hasSVE() && getMinSVEVectorSizeInBits() >= 128; or return hasSVE(); (with the same effect).
This function alone is sufficient to trigger the ICE:
targettriple = "aarch64-unknown-linux-gnu"definevoid@masked_gather_v2f16(<2 x half>* %a, <2 x half*>* %b) vscale_range(2,0) #0 {
%cval = load <2 x half>, <2 x half>* %a%ptrs = load <2 x half*>, <2 x half*>* %b%mask = fcmpoeq <2 x half> %cval, zeroinitializer%vals = call <2 x half> @llvm.masked.gather.v2f16(<2 x half*> %ptrs, i328, <2 x i1> %mask, <2 x half> undef)
store <2 x half> %vals, <2 x half>* %aretvoid
}
declare <2 x half> @llvm.masked.gather.v2f16(<2 x half*>, i32, <2 x i1>, <2 x half>)
attributes #0 = { "target-features"="+sve" }
Removing the vscale_range(2,0) attribute or changing it to vscale_range(1,0) has no impact (i.e., the ICE still occurs).
Here's the output from the ICE in question (note the cyclic pattern of function calls in SelectionDAG):
I'm wondering, would you happen to know whether SVE code generation for the targets with 128-bit SVE registers is meant to be supported--and, possibly, would modifying useSVEForFixedLengthVectors as above be the proper way to go about it or could there be any remaining checks that need to be changed, e.g., in AArch64TargetLowering::useSVEForFixedLengthVectorVT (
I'll have to investigate to confirm details but in general SVE VLS code generation of 128bit and smaller vectors is not well tested and typically only enabled for a handful (but not all) of the cases where SVE has a benefit over NEON. The lowering is controlled via useSVEForFixedLengthVectorVT which takes a flag to say whether it should also return true for NEON sized (i.e. 128 or 64 bit) vectors.
With that said, here we're talking about <2 x half> vectors which are not currently considered type legal for NEON or SVE and so were running into legalisation issues before we get to the phase that would lower to SVE. Looking at the backtrace I'm wondering if we're running out of stack space due to infinite recursion?
Encountering an ICE after removing NEON preference in
useSVEForFixedLengthVectors
for 128-bit vector register size SVE code generation.Context:
There's currently a
>= 256
vector size restriction inuseSVEForFixedLengthVectors
(in "llvm/lib/Target/AArch64/AArch64Subtarget.h").As an experiment I've relaxed it in two different ways, by changing the line in question to
return hasSVE() && getMinSVEVectorSizeInBits() >= 128;
orreturn hasSVE();
(with the same effect).I've then run the build of the modified compiler on the AArch64 LIT tests, encountering an ICE for the following test:
https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AArch64/sve-fixed-length-masked-gather.ll
Compilation using either
clang
orllc
together with the assumed 128-bit SVE register size is sufficient to trigger the ICE:This function alone is sufficient to trigger the ICE:
Removing the
vscale_range(2,0)
attribute or changing it tovscale_range(1,0)
has no impact (i.e., the ICE still occurs).Here's the output from the ICE in question (note the cyclic pattern of function calls in SelectionDAG):
I'm wondering, would you happen to know whether SVE code generation for the targets with 128-bit SVE registers is meant to be supported--and, possibly, would modifying
useSVEForFixedLengthVectors
as above be the proper way to go about it or could there be any remaining checks that need to be changed, e.g., inAArch64TargetLowering::useSVEForFixedLengthVectorVT
(llvm-project/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
Lines 5628 to 5630 in 6f4773f
cc @paulwalker-arm @sdesmalen-arm @stevesuzuki-arm (in case it's relevant to halide/Halide#6781)
The text was updated successfully, but these errors were encountered: