similar to: Assert in TargetLoweringBase.cpp

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

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

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 instead of a scalar register with type i64 . I have the following part of LLVM IR program: vector.body.preheader:

It seems like this routine is not allocating any memory and could just be called a second time. Does anyone know if that is true? I looked at a bunch of it but did not want to create a memory leak by calling it again if it was doing a "new" indirectly somewhere. I've created a clearRegisterClasses method so that we can start all over. Then I would add register classes again and

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

Hello, To any out-of-tree targets, please be aware that I intend to commit a patch that will break the build of any target implementing TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons described below. (Basically, the current interface definition is broken and not followed, and no in-tree target was doing the right thing with it, so it is unlikely any out-of-tree target is either...)

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

I am hoping that someone can offer advice on a somewhat unusual issue that I am facing with the SDAG. Namely, I am trying to implement some custom operations that do very specific things on multiple registers at a time. The operations themselves will simply be intrinsics since there are no equivalent operations in IR/SDAG. However, handling the types seems rather tricky. One approach I tried is

On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: > On Mon, 23 Apr 2007, Christopher Lamb wrote: >> How can one let the back end know how to insert and extract >> elements of >> a vector through sub-register copies? I'm at a loss how to do this... > > You probably want to custom lower the insertelement/extractelement > operations for the cases you support.

How can one let the back end know how to insert and extract elements of a vector through sub-register copies? I'm at a loss how to do this... -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070423/69263896/attachment.html>

I have matrix multiplication and stencil code. I vectorise it through the following command. opt -S -O3 -force-vector-width=2048 stencil.ll -o stencil_o3.ll in both the examples of matrix mult and stencil it vectorises fine when my loop iterations >2048. but if i keep both iterations and vector width=2048. it produces scalar code IR not vectorizes it. Is it llvm bug? Please help me.

Hello. Could you please help me solve the following LLC bug happening at instruction selection time: ISEL: Starting pattern match on root node: t172: ch = store<ST64[FixedStack6]> t0, t6, FrameIndex:i64<6>, undef:i64 Initial Opcode index to 157 Skipped scope entry (due to false predicate) at index 162, continuing at 236 Match failed at

Hello, Tim, Thank you for your advice. Indeed, the problem with "LLVM ERROR: Cannot select" was a false predicate that should have been true. I solved the problem by simply making the C++ function implementing the TableGen predicate used in my store instruction (very similar to the selectIntAddrMSA predicate from the Mips back end) return true instead of false. But

On Mon, 23 Apr 2007, Christopher Lamb wrote: > How can one let the back end know how to insert and extract elements of > a vector through sub-register copies? I'm at a loss how to do this... You probably want to custom lower the insertelement/extractelement operations for the cases you support. Take a look at X86TargetLowering::LowerEXTRACT_VECTOR_ELT for some examples of how to do

On Apr 23, 2007, at 1:17 PM, Christopher Lamb wrote: > > On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: > >> On Mon, 23 Apr 2007, Christopher Lamb wrote: >>> How can one let the back end know how to insert and extract >>> elements of >>> a vector through sub-register copies? I'm at a loss how to do >>> this... >> >> You

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

On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some

Hi, Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some informations that are needed by the vectorization passes to

Hi, I vaguely remember hitting something like this when I was implementing MSA. IIRC, there was an optimization (in DAGCombine or somewhere around there) that was folding CopyToReg instructions into the load without checking whether the new register class was acceptable. I remember adding a target hook to limit this optimization based on the EVT's involved but I'm not sure if that's