search for: instsimplifi

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

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?

While trying to find a solution for this bug http://llvm.org/bugs/show_bug.cgi?id=11235 , I came to the conclusion that the following things can happen while optimizing: - after gvn, I get new constants which are inserted into br and add/sum/..., so there should be at least one more jump-threading and/or instsimplify - after instsimplify, I get new constants which are inserted into br, so there

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

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

On Fri, Dec 2, 2011 at 11:56 AM, Carl-Philip Hänsch <cphaensch at googlemail.com> wrote: > While trying to find a solution for this bug > http://llvm.org/bugs/show_bug.cgi?id=11235 , > I came to the conclusion that the following things can happen while > optimizing: >  - after gvn, I get new constants which are inserted into br and > add/sum/..., so there should be at least

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

[adding llvm-dev for wider audience] On Fri, May 19, 2017 at 12:28 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, May 19, 2017 at 11:00 AM, Davide Italiano <davide at freebsd.org> > wrote: > >> On Fri, May 19, 2017 at 10:00 AM, Sanjay Patel <spatel at rotateright.com> >> wrote: >> > Is "VRP" (value range

On Dec 2, 2011, at 11:56 AM, Carl-Philip Hänsch wrote: > While trying to find a solution for this bug http://llvm.org/bugs/show_bug.cgi?id=11235 , > I came to the conclusion that the following things can happen while optimizing: > - after gvn, I get new constants which are inserted into br and add/sum/..., so there should be at least one more jump-threading and/or instsimplify > -

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:

Hi Benjamin, > LLVM misses this optimization because ScalarEvolution's ComputeExitLimitFromICmp doesn't handle signed<= (SLE) and thus can't compute the number of times the loop is executed. I wonder if there's a reason for this, it seems like something simple to add. instsimplify could also be enhanced to clean it up in this particular case, but it would be better to make

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.

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

<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 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 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 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 a split > like this: > > (1) Search structure > > Suffix tree or suffix array. > > (2) Numbering/mapping/congruence scheme > > Every outliner should implement a function that maps

Hi Chris, this was a very tempting commit to make, unfortunately it broke pattern matching of vectors of booleans. The problem is that a ConstantDataVector is only formed if the element type is one of i8, i16, etc. So vectors of funky types, or not so funky types like i1, are no longer matched. I noticed this while working on PR11948. The good thing is that the testcase there no longer crashes

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