search for: t27

...ake progress on this. Thank you >From your description it seems like you are seeing an incorrect behavior. If that's the case, it should definitely be fixed. Could you provide the complete DAG before and after the erroneous transformation? -Krzysztof Combining: t25: v2i16 = BUILD_VECTOR t27, t22 Before reduceBuildVecToShuffle SelectionDAG has 14 nodes: t0: ch = EntryToken t2: v4i16,ch = CopyFromReg t0, Register:v4i16 %0 // [a b c d] t26: v2i16 = extract_subvector t2, Constant:i32<0> // [a b] t27: i16 = extract_vector_elt t26, Constant:i32<0> // [a]...

...fically handle when the source or target type is v2i16 or v4i16, and for other cases we just return the input SDValue and let the "normal" code handle it in whatever way it see fits. In this particular case, when it crashes, we have a bitcast from v2i64 to v4i32: t70: v4i32 = bitcast t27 and t27 is t27: v2i64 = or t15, t26 so it's a bitcast from v2i64 to v4i32 that we don't want to do anything special with so we return the input SDValue which TargetLowering::LowerOperationWrapper returns back to DAGTypeLegalizer::CustomLowerNode and then we get the assert in DAGTypeL...

...ValueType:ch:i1 t8: v2i32 = BUILD_VECTOR t2, t7 t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 t22: i32 = add t15, Constant:i32<1> t24: ch = CopyToReg t0, Register:i32 %vreg3, t22 t27: ch = CopyToReg t0, Register:i32 %vreg8, Constant:i32<-1> t31: ch = TokenFactor t24, t27 t13: v2i1 = setcc t8, t11, setne:ch t16: i1 = extract_vector_elt t13, t15 t17: i32 = extract_vector_elt t8, t15 t18: i32 = extract_vector_elt t11,...

...8: v2i32 = BUILD_VECTOR t2, t7 > t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> > t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 > t22: i32 = add t15, Constant:i32<1> > t24: ch = CopyToReg t0, Register:i32 %vreg3, t22 > t27: ch = CopyToReg t0, Register:i32 %vreg8, Constant:i32<-1> > t31: ch = TokenFactor t24, t27 > t13: v2i1 = setcc t8, t11, setne:ch > t16: i1 = extract_vector_elt t13, t15 > t17: i32 = extract_vector_elt t8, t15 > t18: i32 = extr...

...ValueType:ch:i1 t8: v2i32 = BUILD_VECTOR t2, t7 t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 t22: i32 = add t15, Constant:i32<1> t24: ch = CopyToReg t0, Register:i32 %vreg3, t22 t27: ch = CopyToReg t0, Register:i32 %vreg8, Constant:i32<-1> t31: ch = TokenFactor t24, t27 t13: v2i1 = setcc t8, t11, setne:ch t16: i1 = extract_vector_elt t13, t15 t17: i32 = extract_vector_elt t8, t15 t18: i32 = extract_vector_elt t11,...

...appening at various stages of DAG optimization: clang -O0 -mllvm -debug -S failing.c -o failing.s The initial selection DAG has the AND op node: t22: i8 = srl t19, Constant:i64<1> * t23: i8 = and t22, Constant:i8<1>* t24: i32 = zero_extend t23 t27: i1 = setcc t24, Constant:i32<1>, seteq:ch t29: i1 = xor t27, Constant:i1<-1> t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> The Optimized lowered selection DAG does not contain the* AND* node, but...

...tion: > > clang -O0 -mllvm -debug -S failing.c -o failing.s > > The initial selection DAG has the AND op node: > > t22: i8 = srl t19, Constant:i64<1> > * t23: i8 = and t22, Constant:i8<1>* > t24: i32 = zero_extend t23 > t27: i1 = setcc t24, Constant:i32<1>, seteq:ch > t29: i1 = xor t27, Constant:i1<-1> > t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> > t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> > > The Optimized lowered selection DAG does not cont...

Hi, I'm a litle bit puzzled by the TargetLowering::LowerOperation function, and what different callers of this function assumes about the returned value. In several places it seems like it is assumed that LowerOperation can return three kinds of values: * Something completely new. * SDValue() * The same SDValue as LowerOperation was called on. However in some places, e.g. in

...ValueType:ch:i1 t8: v2i32 = BUILD_VECTOR t2, t7 t11: v2i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<-23> t15: i32,ch = CopyFromReg t0, Register:i32 %vreg2 t22: i32 = add t15, Constant:i32<1> t24: ch = CopyToReg t0, Register:i32 %vreg3, t22 t27: ch = CopyToReg t0, Register:i32 %vreg8, Constant:i32<-1> t31: ch = TokenFactor t24, t27 t13: v2i1 = setcc t8, t11, setne:ch t16: i1 = extract_vector_elt t13, t15 t17: i32 = extract_vector_elt t8, t15 t18: i32 = extract_vector_elt t11,...

...6, TargetConstant:i64<32>, TargetConstant:i64<0>, t16:1 t20: ch = lifetime.start t17, TargetFrameIndex:i64<0> t21: i64 = Constant<96> t22: i64 = Constant<0> t24: v4i32,ch = load<LD16[%0](align=8)(dereferenceable)> t20, FrameIndex:i64<1>, undef:i64 t27: i64 = add FrameIndex:i64<1>, Constant:i64<16> t28: v4i32,ch = load<LD16[%0+16](align=8)(dereferenceable)> t20, t27, undef:i64 t31: i64 = add FrameIndex:i64<1>, Constant:i64<32> t32: v4i32,ch = load<LD16[%0+32](align=8)(dereferenceable)> t20, t31, undef:i64...

...tion: > > clang -O0 -mllvm -debug -S failing.c -o failing.s > > The initial selection DAG has the AND op node: > > t22: i8 = srl t19, Constant:i64<1> > * t23: i8 = and t22, Constant:i8<1>* > t24: i32 = zero_extend t23 > t27: i1 = setcc t24, Constant:i32<1>, seteq:ch > t29: i1 = xor t27, Constant:i1<-1> > t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> > t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> > > The Optimized lowered selection DAG does not cont...

...uld point me to a document that describes some of these error messages? For example what does t26 ..t4 mean? Thanks in advance for taking your valuable time to help me! Jeff jeff at ubuntu:~/code$ llc dft_gf_msp.ll LLVM ERROR: Cannot select: t28: ch = store<ST2[%le](align=4), trunc to i16> t27, t26, FrameIndex:i32<14>, undef:i32 t26: i32,ch = load<LD2[%sz](align=4), anyext from i16> t25, FrameIndex:i32<2>, undef:i32 t7: i32 = FrameIndex<2> t4: i32 = undef t17: i32 = FrameIndex<14> t4: i32 = undef In function: main LLVMTargetMachine(T, "e...

Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on

...balAddress:i16<float* @x2> 0, undef:i16 t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, GlobalAddress:i16<float* @x3> 0, undef:i16 t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, GlobalAddress:i16<float* @x4> 0, undef:i16 t27: i16 = GlobalAddress<float (float, float, float, float)* @fdivfaddfmul_a> 0 t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, t29:1 t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16&l...

...t; >   t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, > GlobalAddress:i16<float* @x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = GlobalAddress<float (float, float, float, float)* > @fdivfaddfmul_a> 0 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> > >   t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, > t29:1 > >   t33: ch,glue = CLP...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

...> >   t25: f32,ch = load<Volatile LD4[@x3](tbaa=<0x3dbe418>)> t24:1, > GlobalAddress:i16<float* @x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = GlobalAddress<float (float, float, float, float)* > @fdivfaddfmul_a> 0 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> > >   t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, > FrameIndex:i16<0>, > t29:1 > >   t33: ch,glue...

<div> </div><div><div><p>Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more.</p><p>This proposal is to add a <code>llvm.clmul</code> instruction. Or if that is contentious, <code>llvm.experimental.bitmanip.clmul</code> instruction.

...t> %c01, <8 x float> %c2.w, <12 x i32> <i32 0, i32 1, i32 2, i32 undef, i32 4, i32 5, i32 6, i32 undef, i32 8, i32 9, i32 10, i32 undef > ; t26: v12f32 = CONCAT_VECTORS t23, t24, t25 ret <12 x float> %c ;----------- ; t27: v4f32 = EXTRACT_SUBVECTOR t26, 0 ; t28: v4f32 = EXTRACT_SUBVECTOR t26, 4 ; t29: v4f32 = EXTRACT_SUBVECTOR t26, 8 ; t42: ch,glue = CopyToReg t0, Register:v4f32 $q0, t27 ; t44: ch,glue = CopyToReg t42, Register:v4f32 $q1, t28, t42:1 ; t46: ch,glue = CopyToReg t44, Register:v4f32 $q2, t29...