@llvm/issue-subscribers-backend-aarch64

Author: Vitaly Buka (vitalybuka)

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 [2 x i64] @<!-- -->_ZNSt3__121__mismatch_vectorizedB8ne200000IPiEENS_4pairIT_S3_EES3_S3_S3_() personality ptr null {
entry:
  %extractvec60 = shufflevector &lt;8 x i1&gt; zeroinitializer, &lt;8 x i1&gt; zeroinitializer, &lt;1 x i32&gt; zeroinitializer
  %insertvec62 = shufflevector &lt;1 x i1&gt; %extractvec60, &lt;1 x i1&gt; zeroinitializer, &lt;8 x i32&gt; &lt;i32 0, i32 poison, i32 poison, i32 poison, i32 poison, i32 poison, i32 poison, i32 poison&gt;
  %0 = bitcast &lt;8 x i1&gt; %insertvec62 to i8
  store i8 %0, ptr null, align 1
  ret [2 x i64] zeroinitializer
}

; uselistorder directives
uselistorder ptr null, { 1, 2, 3, 0 }

assert.h assertion failed in void llvm::MachineIRBuilder::validateTruncExt(const LLT, const LLT, bool): DstTy.isScalar() && SrcTy.isScalar() && "invalid extend/trunc"

This bisects to #83038

@davemgreen @stuij @aemerson please help?
IR looks reasonable to me.

Is this assert just wrong https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp#L1185 ?

How do we make this crash? I wasn't able to here: https://llvm.godbolt.org/z/fxnnxMzvK (I can fully believe that it would). @aemerson has been trying to fix up some of the vector-i1 lowering lately, maybe we have fixed/hidden the problem recently.

How do we make this crash? I wasn't able to here: https://llvm.godbolt.org/z/fxnnxMzvK (I can fully believe that it would). @aemerson has been trying to fix up some of the vector-i1 lowering lately, maybe we have fixed/hidden the problem recently.

I passed that into clang, same sh script from the gz with -x ir reduced.ll
I guess the must be a way reproduce with llc, but I didn't try.

Something like this:

clang -cc1 -triple aarch64-unknown-linux-gnu -S -x ir reduced.ll -o -

and to avoid store to null we can change to

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 [2 x i64] @_ZNSt3__121__mismatch_vectorizedB8ne200000IPiEENS_4pairIT_S3_EES3_S3_S3_(ptr %p) {
entry:
  %extractvec60 = shufflevector <8 x i1> zeroinitializer, <8 x i1> zeroinitializer, <1 x i32> zeroinitializer
  %insertvec62 = shufflevector <1 x i1> %extractvec60, <1 x i1> zeroinitializer, <8 x i32> <i32 0, i32 poison, i32 poison, i32 poison, i32 poison, i32 poison, i32 poison, i32 poison>
  %0 = bitcast <8 x i1> %insertvec62 to i8
  store i8 %0, ptr %p, align 1
  ret [2 x i64] zeroinitializer
}

Ah of course, it just needed -O0 to llc to prevent it being simplified.
https://llvm.godbolt.org/z/hdE6Ksxz6

Ah of course, it just needed -O0 to llc to prevent it being simplified. https://llvm.godbolt.org/z/hdE6Ksxz6

Nice. I also tried a little with opt, and notices that it simplifies store, but it didn't trigger with me that llc may transform it some how as well.

yes, it crashes the same in MachineIRBuilder::validateTruncExt
DstTy=s8
SrcTy=<8 x s1>

It looks like it doesn't handle <1 x i1> shuffle vectors (as gisel converts any <1 x > vector to a scalar, and nothing under -O0 canonicalized the shuffle to just an extract).
https://llvm.godbolt.org/z/K7hvW85MW

Thank you for the quick fix, David!