similar to: [llvm] r303387 - [InstCombine] add more tests for xor-of-icmps; NFC

This can't be an instsimplify though? The values we want in these cases do not exist already: %res = or i8 %b, %a %res = or i1 %cmp, %c On Thu, Jul 13, 2017 at 5:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, Jul 13, 2017 at 2:12 PM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> We have several optimizations in InstCombine

We have several optimizations in InstCombine for bitwise logic ops (and/or/xor) that fail to handle compare patterns with the equivalent bitwise logic. Example: define i8 @or_and_not(i8 %a, i8 %b) { %nota = xor i8 %a, -1 %and = and i8 %nota, %b %res = or i8 %and, %a ret i8 %res } define i1 @or_and_cmp_not(i32 %a, i32 %b, i1 %c) { %cmp = icmp sgt i32 %a, %b %cmp_inv = icmp sle i32 %a,

David/Johan, I would love to claim victory, but I don't think that D34901 catches this case. However, I got interested and threw this together quickly: https://reviews.llvm.org/D35140. This does catch the below case. If people are interested I can add test cases and submit for formal review. FWIW, it does hit about 1/3 of all of the SPEC benchmarks. I haven't done any performance

On Fri, Jul 14, 2017 at 10:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > >> I think you're done when you get everything that you have that fits into >> a model of local transformations and that should be run to a fixed point. >> > > Sure, but to point out what you certainly already know, that's almost > every optimization you can think of

On 07/13/2017 06:40 PM, Daniel Berlin via llvm-dev wrote: > Ah yes, it can only return one instruction and you need two. > > NewGVN could still handle it if instsimplify was changed to return the > right binary operators because it has infrastructure that can handle > insertion. > (it would need a little work). > > > (At this point, InstCombine seems to have become

On 07/14/2017 10:27 AM, Daniel Berlin wrote: > > > On Thu, Jul 13, 2017 at 6:18 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 07/13/2017 06:40 PM, Daniel Berlin via llvm-dev wrote: >> Ah yes, it can only return one instruction and you need two. >> >> NewGVN could still handle it if instsimplify was

> On Sep 27, 2017, at 3:23 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I think that, given previous discussion on the topic, we might want a split >> like this: >>

On 15 January 2015 at 10:49, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Jan 15, 2015 at 10:30 AM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> Would it be wrong to generate the llvm.assume IR suggested below? in GVN? >> > > I think so... Because: > > One very small tweak you could make would be to add an llvm.assume inside

Hi, I think we should remove the LoopInstSimplify pass, as it has no test coverage and no users (afaik). If you are using the pass, or think that it should stay in tree for some other reason, please let me know. Here's the patch: https://reviews.llvm.org/D44053 <https://reviews.llvm.org/D44053> vedant -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, It's been a while since I sent the last compile time report [1], where it was shown that LLVM was getting slower over time. But now I'm happy to bring some good news: finally, LLVM is getting faster, not slower :) *** Current status *** Many areas of LLVM have been examined and improved since then: InstCombine, SCEV, APInt implementation, and that resulted in almost 10% improvement

Thanks for sharing this background information :). If you've got the time, I think it'd be great to check this bulleted list into docs/. I see that we don't have a Canonicalizations.rst or a LoopOptimizations.rst -- your notes look like a good starting point. Given that the pass seems to be doing the right thing from a design perspective, should it stay in tree? Since it's been

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy

<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

On Wed, Sep 27, 2017 at 6:07 PM, Matthias Braun <mbraun at apple.com> wrote: > > On Sep 27, 2017, at 3:23 PM, Davide Italiano via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > I think that, given previous discussion on the topic, we might want

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?

Hello, My name is Siddharth. I’m a student studying math and computer science at the University of Toronto. I’m interested in learning more about the LLVM compiler through GSoC. I have no prior experience with LLVM, but I have a strong interest in compilers, and I look forward to learning more. I would like to pursue one of two potential projects: rewriting bugpoint, and moving optimizations

We're not actively using this, but from a design perspective I'm wondering if we should be using this or something like it.  At the moment, our various loop optimization assume mostly canonical input.  Some of the passes have been taught to deal with limited amounts of non-canonical-ism, but there's a strong code simplicity argument in favor of only handling canonical input and

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

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

(and sys::cas_flag that STATISTIC uses is a uint32 ...) On Thu, Aug 25, 2016 at 9:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > Okay, dumb question: > Are you really getting negative numbers in the second column? > > 526,766 -136 mem2reg # PHI nodes inserted > > http://llvm.org/docs/doxygen/html/PromoteMemoryToRegister_8cpp_source.html >