similar to: [LLVMdev] Simplifying selects + arm stuff

On Nov 10, 2010, at 11:39 PM, Chris Lattner wrote: >> > > Yeah, that's not nearly as good as "%r = and i32 %x, %y" :) > > Note that: > > %z = select i1 %cond, i32 -1, i32 %x > %s = and i32 %z, %y > > Is a "conditional and". It would be interesting to know if the ARM backend gets this as a single predicated 'and' instruction

Hi Chris, > Instead of turning this into a phase ordering issue, I'd rather increase the power of the folding logic to catch the general form. In this case, instead of handling this in instsimplify, why not handle this in reassociate? > > This is conceptually no different than (x& y& x) -> (x& y), it's just that in this case you have: (x& y& (x or

On Nov 12, 2010, at 11:04 AM, Evan Cheng wrote: >> %z = select i1 %cond, i32 -1, i32 %x >> %s = and i32 %z, %y >> >> Is a "conditional and". It would be interesting to know if the ARM backend gets this as a single predicated 'and' instruction (similarly for the 'or' and 'xor' version of these patterns). I bet not, which is bad if

Eli Friedman <eli.friedman <at> gmail.com> writes: > > Empirically the OSR optimization is compile-time faster than LSR. I have > > also noticed that OSR has more "analysis" requirements: Induction Variable > > User, Natural Loop Information, Canonicalize natural loops, and Scalar > > Evolution Analysis. Both OSR and LSR require the Dominator Tree

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

On Nov 12, 2010, at 11:09 AM, Chris Lattner wrote: > On Nov 12, 2010, at 11:04 AM, Evan Cheng wrote: >>> %z = select i1 %cond, i32 -1, i32 %x >>> %s = and i32 %z, %y >>> >>> Is a "conditional and". It would be interesting to know if the ARM backend gets this as a single predicated 'and' instruction (similarly for the 'or' and

Eli Friedman <eli.friedman <at> gmail.com> writes: > >> > I did not mention in the original email (and should have) that OSR needs > >> > -instcombine to be run after it for cleanup. Also -licm, -reassociate, -gvn > >> > and -sccp can be enabling optimizations for OSR. > >> > >> Hmm... perhaps that could be partially fixed

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 > >

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

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

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?

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

On Thu, Oct 28, 2010 at 9:38 AM, Brian West <bnwest at rice.edu> wrote: >> 3. LLVM already has a significant amount of infrastructure for loop >> passes; why does this pass have its own code for finding loops? > > I saw the loop infrastructure for CFG loops. This algorithm finds loops in > the data flow (more precisely: strongly-connected components in the >

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not

On 10/27/10 8:34 PM, Eli Friedman wrote: > On Wed, Oct 27, 2010 at 1:29 PM, Brian West<bnwest at rice.edu> wrote: >> Here is the patch for the new Operator Strength Reduction optimization >> pass that I have written. The bulk of the code is in >> >> lib/Transforms/Scalar/OperatorStrengthReduce.cpp >> >> The algorithm finds reduction opportunities in

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

The LangRef says this for left shifts: "If the nsw keyword is present, then the shift produces a poison value if it shifts out any bits that disagree with the resultant sign bit." ... (1) followed by "As such, NUW/NSW have the same semantics as they would if the shift were expressed as a mul instruction with the same nsw/nuw bits in (mul %op1, (shl 1, %op2))." ... (2) But

Hi, I am investigating a performance degradation between llvm-3.1 and llvm-3.2 (Note: current top-of-tree shows a similar degradation) One issue I see is the following: - 'loop invariant code motion' seems to be depending on the result of the 'reassociate expression' pass: In the samples below I observer the following behavior: Both start with the same expression: %add = add