similar to: [LLVMdev] Redundant Add Operation in Code Generation?

That solves the issue but it seems odd to me that instcombine doesn't take care of it? So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant operations, should it not clean itself up? Or am I mistaken? On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 17, 2012, at 1:22 PM,

Ok, thanks. Even still though I would expect -instcombine (run after lsr) would do this cleanup? On Fri, Oct 19, 2012 at 2:41 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > That solves the issue but it seems odd to me that instcombine doesn't take > care of it? > > > LSR is

On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45

On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45

Eli, Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. behavior? It seems to me that codegenprepare is doing a useful thing (for me, since I'm just using the llvm IR and not going to backend, providing it's "exposing" and not simply "adding for layout for CodeGen opts" (or something similar to this)? Thanks. On Wed, Oct 17, 2012 at 1:44

On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That solves the issue but it seems odd to me that instcombine doesn't take care of it? LSR is part of the backend. It's lowering the IR for a specific target. It seems to think those redundant operations are good for reducing register pressure, but doesn't actually have much knowledge about register

On Oct 19, 2012, at 2:44 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks. > > Even still though I would expect -instcombine (run after lsr) would do this cleanup? It's valid to run any IR pass after -loop-reduce. So you can try it. -gvn is probably what you're looking for. It isn't something we normally want to do. Turn off LSR if it does bad things on

Eli, Actually, I stil see this issue without codegenprepare being used. I'm also compiling with -o3. So I'm still not sure why I'm seeing this issue? Thanks. On Wed, Oct 17, 2012 at 1:54 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Eli, > > Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. > behavior? > > It seems to me

Wojciech, I've just commited a patch to llvm-gcc 4.2, which moves openmp lowering stuff to be run little bit earlier, so llvm-convert will catch its result. It looks now gcc atomic & sync builtins should be introduced to llvm as a remaining ingredient. Example program from Diego's paper now compiles to: @.str = internal constant [10 x i8] c"sum = %d\0A\00" ;

Hi Jeroen, Sorry, I missed that. I tried the patch, and this program: #include <stdint.h> #define __remote __attribute__((address_space(1))) __remote int* A; __remote int* B; void vec_add(__remote int* __restrict a, __remote int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } int main(int argc, char** argv) {

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

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 Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com>

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S:

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S:

I'm attempting to modify a parser generator to emit LLVM code instead of C. So far the experience has been trivial, but I am now running into an error regarding labels that I can't seem to solve. Situation 1: A label is used immediately after a void function call (l6 in this case): <snip> %tmp26 = load i32* @yybegin, align 4 %tmp27 = load i32* @yyend, align 4 call void

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

Hi all, while writing a testcase thate needed to do a grep containg {, I found that the DejaGNU test framework didn't handle those very well. It's a bit of a fuss to escape accolades properly, but most of all the framework seemed to silently ignore errors in the escaping (and just not run the command then). See [1]. Fixing the framework resulted in 80 of the tests failing. I spent the