search for: instructionsimplifi

Running a build on r122586, gave me the following warnings with: gcc version 4.2.1 (Apple Inc. build 5664) =================================================== <dir>/llvm/lib/Analysis/InstructionSimplify.cpp:82: warning: comparison between signed and unsigned integer expressions <dir>/llvm/lib/Analysis/InstructionSimplify.cpp:106: warning: comparison between signed and unsigned

Apologies if this has come up before. I couldn't find any previous discussion, but I did find this commit. I was wondering why LLVM cannot optimize this code (which GCC does optimize): int f(int *p) { int x; return p == &x; } it would seem that this must always return 0. (This occurs as a self-assignment check in the code I was looking at; I was hoping we could fold that check away.)

I'm looking for some opportunities to contribute to the LLVM core without too big of a learning curve. The open projects page<http://llvm.org/OpenProjects.html#misc_imp>suggests moving logic from the instruction combining transformation to the InstructionSimplify analysis. But it looks like some work has been done there since the projects page was last edited. Is there more benefit to

As Sanjay noted in D31426<https://reviews.llvm.org/D31426#712701>, InstructionSimplify is missing the following simplification: This function: define <4 x i32> @splat_operand(<4 x i32> %x) { %splat = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> zeroinitializer %shuf = shufflevector <4 x i32> %splat, <4 x i32> undef, <4 x i32>

Hi folks, I'm hitting the below assertion failure when compiling this small piece of C code (repro.c, attached). My command line is: bin/clang --target=aarch64-linux-gnu -c -O2 repro.c clang is built from top of trunk as of this morning. It only happens at -O2, and it doesn't happen with the default target (x86_64). I tried to reproduce using just 'llc -O2' but didn't

On Thu, Sep 24, 2015 at 12:06 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Sep 24, 2015 at 2:42 PM, Hans Wennborg <hans at chromium.org> wrote: >> I was wondering why LLVM cannot optimize this code (which GCC does optimize): >> >> int f(int *p) { int x; return p == &x; } >> >> it would seem that this must always return 0. (This

I threw together a patch which implements this (attached.) If we decide that this is actually a legal transform, I'm happy to post this for review. In addition to the version proposed here, I also implemented a case where a trivially escaped alloca's address is not equal to any other value. I believe both are valid, but we should confirm. Philip On 09/24/2015 02:34 PM, Aaron

Sure. David, what do you think about merging this to 3.9? Sanjay: are you saying I'd just apply that diff to InstructionSimplify.cpp, not InstCombineSelect.cpp? On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Hi Hans - > > Yes, I think this is a good patch for 3.9 (cc'ing David Majnemer as code > owner). The functional change was

Thanks for notifying me. Yes, this was a recent change. Taking a look now. On Wed, Jul 20, 2016 at 1:49 PM, Michael Kuperstein <mkuper at google.com> wrote: > +Sanjay, who touched this last. :-) > > On Wed, Jul 20, 2016 at 12:44 PM, Ismail Badawi (ibadawi) via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi folks, >> >> I'm hitting the

On 09/24/2015 06:04 PM, Hans Wennborg wrote: > I tried your patch on a Clang build to see if it would fire. It > reduced the size of a bootstrap with 8500 bytes. Not huge, but it > seems like a nice improvement. And maybe it could be made more > powerful: not just checking if the address is a param or alloca, but > an address based on such values. Yeah, I realized after posting that

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

David, Sanjay: ping? On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org> wrote: > Sure. David, what do you think about merging this to 3.9? > > Sanjay: are you saying I'd just apply that diff to > InstructionSimplify.cpp, not InstCombineSelect.cpp? > > On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: >> Hi

LGTM On Wednesday, July 27, 2016, Hans Wennborg <hans at chromium.org> wrote: > David, Sanjay: ping? > > On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > > Sure. David, what do you think about merging this to 3.9? > > > > Sanjay: are you saying I'd just apply that diff to > >

Dear all, If possible, I would like to contribute to LLVM. First of all, I would like to say that I'm a newbie in LLVM, and my experience in compilers implementation is only in simples and academics "toy projects". My main interesting are focused in try to improve the code generated by LLVM, where "improve" I mean "better performance". I'm interested, for

<cc'ing llvmdev> On Nov 10, 2010, at 6:38 AM, Duncan Sands wrote: > Hi Chris, in commit 12800 you introduced the following transform: > > Implement select.ll:test12* > > This transforms code like this: > > %C = or %A, %B > %D = select %cond, %C, %A > into: > %C = select %cond, %B, 0 > %D = or %A, %C > > Since B is often a

Thanks, Sanjay, that makes sense. The opportunity for improving instcombining splat sounds promising. Another question about shuffle simplification. This is a testcase from test/Transforms/InstCombine/vec_shuffle.ll: define <4 x i32> @test10(<4 x i32> %tmp5) nounwind { %tmp6 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32

Hi Duncan, Thank you a lot for your time to provide that great and informative explanation. Now the "undef" logic makes much more sense for me. >> /You are wrong to say that "div undef, %X" is folded to "undef" by InstructionSimplify, it is folded to zero./ My mistake. I meant to say "*f****div* undef, %X" is folded to "undef" (not

There's some interest in my "auto-simplifier", which is nice :), so let me explain a bit about it. On 19/01/11 19:35, Sandeep Patel wrote: > You've mentioned your auto-simplifier a few times now and curiosity is > getting the better of me. Can you explain it a bit more? On 20/01/11 00:32, Nuno Lopes wrote: > Just out of curiosity, what's this auto-simplifier?

Hi Duncan, Thank you for your comment to the bug 16257. I am new to LLVM, so not all the aspects of LLVM's /"undef"/ seem clear to me yet. I read and understood the examples from the LLVM documentation: http://llvm.org/docs/LangRef.html#undefined-values However, those examples do not cover all of the possible contexts where /"undef"/ can appear. E.g., I can't

Duncan, > Hi Oleg, > >> >> /This is either a mistake, or a decision that in LLVM IR snans >> are always >> considered to be signalling. / >> Yes, this seems to be an agreement to treat "undef" as a SNaN for >> "fdiv". > > "undef" is whatever bit pattern you want it to be, i.e. the compiler > can assume it is any