similar to: [LLVMdev] [llvm-commits] [llvm] r123754 - in /llvm/trunk: lib/Analysis/InstructionSimplify.cpp test/Transforms/InstSimplify/2010-12-20-Distribute.ll

Today, InstSimplify calls computeKnownBits to try to fold to a constant ONLY if it can't find any other simplifications for an instruction. I think this means if we are able to find an earlier simplification we are LESS aggressive about creating a constant because we won't even look at known bits. This seems surprising to me. Should we be looking at known bits always, or should we remove

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

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>

On Wed, Jan 16, 2013 at 12:53:55AM +0100, Joerg Sonnenberger wrote: > 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 equal. Let's take the version with the cleanup from IRC. *sigh* Dealing with too many copies. Joerg -------------- next part -------------- Index:

<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

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

On Fri, Jun 29, 2012 at 3:10 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. > > Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, > and that this is source of many problems (most notably with traps) and > code duplication.

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

A few random observations: 1. Clang could do better with large but boring switches like this: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/E8/E88C5111.shtml Performance of clang's output will be fine but this is a major code size lose. 2. Destruction of stupid loops is incomplete, sometimes due to phase ordering problems:

> I wouldn't be surprised if InstSimplify were relying on (1) to implement > some of its optimizations: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/InstructionSimplify.cpp?revision=233938&view=markup#l2298 Yup! It looks like LLVM really implements (1) and (2) is just a misleading anecdote. So I'll change my vote from "remove (1)" to "remove

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

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

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

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 Hal, James told me that in PassManagerBuilder.cpp, BarrierNoopPass is already used for this kind of purpose(though there's also a fixme saying it's hacking). I think it's a good idea to use this pass here. Thanks, Kevin 2015-03-11 17:05 GMT+08:00 Hal Finkel <hfinkel at anl.gov>: > ----- Original Message ----- > > From: "Kevin Qin" <kevinqindev at

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

First, I love R and am grateful to be using this free and extremely high quality software. Recently I have been comparing two algorithms and naturally I programmed in R first. It is so slow that I can almost feel its pain. So I decided to do a comparison with Java. To draw 500,0000 truncated normal, Java program takes 2 second and R takes 72 seconds. Not a computer science major, I find it hard

On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the