search for: v8i64

...x i64> %.splatinsert56, <8 x i64> undef, <8 x i32> zeroinitializer %induction58 = add <8 x i64> %.splat57, <i64 0, i64 -1, i64 -2, i64 -3, i64 -4, i64 -5, i64 -6, i64 -7> br label %vector.body25 The exact problem reported is: Selecting: t51: v8i64,ch = load<LD64[ConstantPool]> t0, ConstantPool:i64<<8 x i64> <i64 0, i64 1, i64 2, i64 3, i64 4, i64 5, i64 6, i64 7>> 0, undef:i64 ISEL: Starting pattern match on root node: t51: v8i64,ch = load<LD64[ConstantPool]> t0, ConstantPool:i64<<8 x i64> &l...

...), r0 std -128(r10), REGVEC0 jmp LBB0_4 LBB0_4: // %vector.body ldd REGVEC0, -128(r10) ldd r0, -48(r10) I am surprised that the BPF scalar instructions ldd and std use vector register REGVEC0, which have type v8i64. For example, the TableGen definition of the LOAD instruction taken from BPFInstrInfo.td is: class LOADi64<bits<2> SizeOp, string OpcodeStr, PatFrag OpNode> : LOAD<SizeOp, OpcodeStr, [(set i64:$dst, (OpNode ADDRri:$addr))]>; So I am surprised that the...

...ering an initial attempt. > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex > Susu via llvm-dev > Sent: 28 June 2016 20:44 > To: llvm-dev > Subject: [llvm-dev] Instruction selection problem with type i64 - mistaken as > v8i64? > > Hello. > I am writing a back end in which I combined the existing BPF LLVM back > end with the > Mips MSA vector extensions (from the Mips back end) > I have encountered an error when compiling with llc: the instruction > selector uses a > vector register...

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

...x to 157 Skipped scope entry (due to false predicate) at index 162, continuing at 236 Match failed at index 241 Continuing at 263 LLVM ERROR: Cannot select: t172: ch = store<ST64[FixedStack6]> t0, t6, FrameIndex:i64<6>, undef:i64 t6: v8i64,ch = CopyFromReg t0, Register:v8i64 %vreg19 t5: v8i64 = Register %vreg19 t171: i64 = FrameIndex<6> t73: i64 = undef In function: foo I actually have difficulties in understanding in the Selection DAG what the FixedStack operand means. Also, i...

This post is related to the following post http://lists.llvm.org/pipermail/llvm-dev/2016-April/098823.html I'm still trying to compile a library with clang. But now I'm getting as assert in lib/CodeGen/TargetLoweringBase.cpp:1155: virtual llvm::EVT llvm::TargetLoweringBase::getSetCCResultType(llvm::LLVMContext&, llvm::EVT) const: Assertion `!VT.isVector() && "No default

...the SDAG that the correspondingly wide type can go into those registers. While this works, it has a very unfortunate side effect that the type legalizer leaves any node with such a type untouched and I have to mark all operations as non-legal (mostly Expand). For example, I could say that the type v8i64 can go into these registers and then I can use the type for my intrinsics. However, the type legalizer will leave all nodes with this result/operand type alone which is not at all what I want. Then I tried the opposite approach - just custom lower only specific nodes that have this result type and...

...gdb) print Vals[3] $4 = {Node = 0x6c18b0, ResNo = 0} Before i-sel started, store had as inputs a TokenFactor, an add, a CopyFromReg (I can provide the entire DOT output with -view-isel-dags) and an undef. If we give during i-sel, at InitOperands(): (gdb) print Ops[0].Val.Node->dump()t19: v8i64 = add t18, t17 So, Ops[0] is add. So, the problem is that after instruction selection of a RET, CopyToReg and TokenFactor I have a messed-up SelectionDAG, with the problems mentioned above for the select instruction that cause the segfault. Did anybody encounter a similar problem...

I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good

Hello. I'm writing a back end for a RISC processor (similar to BPF) with a large SIMD unit. I tried in the last days to make llc compile to SIMD code the following LLVM program: define i32 @foo(i32* %A, i32* %B, i32* %C, i32 %N) #0 { entry: ;vector.body: ; preds = %vector.body, %vector.body.preheader.split.split %0 = getelementptr inbounds i32, i32* %A, i64 0 ; i64 %index ; Alex: I

...i64, undef:i64, undef:i64, undef:... Split node result: t125: v16i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64... Split node result: t126: v8i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64... Split node result: t127: v4i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, undef:i64... Split node result: t128: v2i64 = BUILD_VECTOR undef:i64, undef:i64 Split node operan...

...nd* >>>>> >>>> >>>> You have to look at the size of the register being mentioned and the >>>> number of elements in brackets. In this case the regsiter is 512-bits and >>>> the number of elements is 8. 512/8 is 64. So its a shuffle of a v8i64 >>>> vector. Then we read the element numbers from left to write just like the >>>> shuffle IR instruction. >>>> >>>> So element 0 of zmm1 gets the value of element 4 of zmm0. Element 1 of >>>> zmm1 gets the value of element 5 of zmm5, etc...

...changes and decided that this is not the way to go. _Packed_ I followed Duncan’s original suggestion which was packing vectors of i1s into general purpose registers. I started by adding several new types to ValueTypes (td and h).  I added ‘4vi1, 8vi1, 16vi1 … 64vi1’.  For x86, I mapped the v8i1 .. v8i64 to general purpose x86 registers. I started playing with a small program, which performed a vector CMP on 4 elements. The legalizer promoted the v4i1 to the next legal pow-of-two type, which was v8i1. I changed WidenVecRes_SETCC and added a new method WidenVecOp_Select to handle the legalization o...

...f:i64, > undef:... > Split node result: t125: v16i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64... > Split node result: t126: v8i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64... > Split node result: t127: v4i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, > undef:i64... > Split node result: t128: v2i64 = BUILD_VECTOR undef:i64, undef:i64 > &g...

Hello. Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have to say that the definition of the "multiclass avx512_gather" from lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it. I currently have some serious problems with TableGen - it gives an assertion failure: