search for: load17

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

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.

...%1 = bitcast i32* %0 to <16 x i32>* %wide.load = load <16 x i32>, <16 x i32>* %1, align 4 %2 = getelementptr inbounds i32, i32* %B, i64 0 ; i64 %index ; Alex: I guess this is useless, since offset is 0 - but we keep this redundancy %3 = bitcast i32* %2 to <16 x i32>* %wide.load17 = load <16 x i32>, <16 x i32>* %3, align 4 %4 = add nsw <16 x i32> %wide.load17, %wide.load %5 = getelementptr inbounds i32, i32* %C, i64 0 %6 = bitcast i32* %5 to <16 x i32>* store <16 x i32> %4, <16 x i32>* %6, align 4 %res = load i32, i32* %C, align 4 ret i3...

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

...at 0x07810000: load15a ALLOC LOAD > READONLY CODE HAS_CONTENTS > ??? 0x7f73f050d000->0x7f73f050d000 at 0x07811000: load15b ALLOC > READONLY CODE > ??? 0x7f73f050f000->0x7f73f050f000 at 0x07811000: load16 ALLOC READONLY > ??? 0x7f73f070e000->0x7f73f070f000 at 0x07811000: load17 ALLOC LOAD > HAS_CONTENTS > ??? 0x7f73f070f000->0x7f73f0710000 at 0x07812000: load18a ALLOC LOAD > READONLY CODE HAS_CONTENTS > ??? 0x7f73f0710000->0x7f73f0710000 at 0x07813000: load18b ALLOC > READONLY CODE > ??? 0x7f73f0712000->0x7f73f0712000 at 0x07813000: load19...

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

...0c000->0x7f73f050d000 at 0x07810000: load15a ALLOC LOAD READONLY CODE HAS_CONTENTS 0x7f73f050d000->0x7f73f050d000 at 0x07811000: load15b ALLOC READONLY CODE 0x7f73f050f000->0x7f73f050f000 at 0x07811000: load16 ALLOC READONLY 0x7f73f070e000->0x7f73f070f000 at 0x07811000: load17 ALLOC LOAD HAS_CONTENTS 0x7f73f070f000->0x7f73f0710000 at 0x07812000: load18a ALLOC LOAD READONLY CODE HAS_CONTENTS 0x7f73f0710000->0x7f73f0710000 at 0x07813000: load18b ALLOC READONLY CODE 0x7f73f0712000->0x7f73f0712000 at 0x07813000: load19 ALLOC READONLY 0x7f73f09...