search for: predsimplifi

Hi John, John Regehr wrote: > PredicateSimplifier is a pretty interesting pass, but it doesn't look > like opt invokes it at any standard -Ox level, and so I assume that > llvm-gcc also does not use this pass? If that is right, I'm curious > about why this is the case -- does it simply not provide enough code > speedup to compensate for the increase in compile time? I

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

PredicateSimplifier is a pretty interesting pass, but it doesn't look like opt invokes it at any standard -Ox level, and so I assume that llvm-gcc also does not use this pass? If that is right, I'm curious about why this is the case -- does it simply not provide enough code speedup to compensate for the increase in compile time? Also, a colleague and I (we both teach advanced

> Predsimplify is believed to have bugs (it results in miscompiled > programs) and certainly isn't efficient (it was written before much of > include/ADT). Finally, predsimplify is likely to go away once I or > someone else writes a proper VRP pass. Whoever does this, I strongly encourage looking into using (or at least providing optional support for) the Apron library:

Hi all, I'm hitting the following assert in PredicateSimplifier.cpp:961 : assert(!CR.isSingleElement() && "Refusing to store single element."); If I ignore it the generated code appears correct so I'm not sure what this assert is supposed to be for. Am I doing something wrong on my end or is this a superfluous assert or it really indicates an LLVM bug? The

Would it be wrong to generate the llvm.assume IR suggested below? in GVN? Given more info via the AssumptionCache, InstCombine can then do more optimizing. On Thu, Dec 4, 2014 at 12:10 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 12/04/2014 02:19 AM, Lars Rasmusson SICS wrote: > > Hi, > > I'm compiling a large code base that uses tagged data, with

On Tue, Feb 22, 2011 at 6:19 AM, Duncan Sands <baldrick at free.fr> wrote: > the big problem with Patterson's VRP is that it is expensive in terms of > compile time.  LLVM used to have some passes (ABCD, predsimplify) that did > this kind of thing, but they were removed essentially because their compile > time was too great for the goodness they brought. Any reason not to

On Wed, 9 Jul 2008, Nicolas Capens wrote: > I'm hitting the following assert in PredicateSimplifier.cpp:961 : Hi Nicolas, The predsimplify pass is experimental at best, and should be removed at worst. I don't think it is going to be futher developed, so I'd suggest staying away from it. -Chris > > > assert(!CR.isSingleElement() && "Refusing to store

Hi Andrey, > On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: >> My work is not part of the LLVM mainline yet. But I would be happy to >> contribute with the code of my range analysis implementation if it can help >> you in something else. > We were thinking of adding VRP to LLVM too, though we were mostly > interested in Patterson's approach (i.e. not

On Feb 15, 2009, at 10:08 PM, John Regehr wrote: >> Predsimplify is believed to have bugs (it results in miscompiled >> programs) and certainly isn't efficient (it was written before much >> of >> include/ADT). Finally, predsimplify is likely to go away once I or >> someone else writes a proper VRP pass. > > Whoever does this, I strongly encourage looking

Hi Douglas, On 21.02.2011 20:27, Douglas do Couto Teixeira wrote: > My work is not part of the LLVM mainline yet. But I would be happy to > contribute with the code of my range analysis implementation if it can help > you in something else. We were thinking of adding VRP to LLVM too, though we were mostly interested in Patterson's approach (i.e. not connected with SSI form). It

On Feb 8, 2011, at 1:15 AM, Mark Shannon wrote: > Nick Lewycky wrote: >> Duncan Sands wrote: >>> Here is a new and improved version that also does the following: if the >>> condition for a conditional branch has the form "A && B" then A, B and the >>> condition are all replaced with "true" in the true destination (similarly

Duncan Sands wrote: > Here is a new and improved version that also does the following: if the > condition for a conditional branch has the form "A && B" then A, B and the > condition are all replaced with "true" in the true destination (similarly > for || conditions in the false destination). Also, if the condition has > the form "X == Y" then X

Nick Lewycky wrote: > Duncan Sands wrote: >> Here is a new and improved version that also does the following: if the >> condition for a conditional branch has the form "A && B" then A, B and the >> condition are all replaced with "true" in the true destination (similarly >> for || conditions in the false destination). Also, if the condition

A longstanding project on the LLVM "open projects" page is to run random C code through random LLVM passes. We have found many LLVM bugs by doing the first of these, but not the second: we test only -O[0123s]. Slowly but surely, LLVM is evolving resistance to our random tester. Of course this is good, but it means that we need to keep expanding our efforts if we want to continue

Chris do you have a sense for how the definedness of signed overflow in LLVM would play out in the context of bounds check elimination? That is, would it cause lots of failure to eliminate checks that could be seen to be unnecessary at the C level? John On Sun, 15 Feb 2009, Chris Lattner wrote: > > On Feb 15, 2009, at 10:08 PM, John Regehr wrote: > >>> Predsimplify is

On Nov 30, 2007, at 20:59, Jon Harrop wrote: > Does LLVM hoist bounds checks out of inner loops? In practice, LLVM is frequently going to have conservative behaviors which will prevent hoisting the explicit bounds checks your front-end must generate. Specifically, LLVM must use alias analysis to disprove the hypothesis that the array length variable is updated by the body of the loop.

Hi, I've been thinking about a (potentially lazy) value tracking analysis that could be reused by several optimization passes. I don't know if it exists in llvm or not, but to my better knowledge it does not. ok there exists the ValueTracking class, but it does not provide a function like e.g. MayHaveTheValue(Value* v, APSInt x) to check if a given var v may ever have the value x My

I have a simple test .ll file that does something like.. int i = 0; if (argc < 1) i++; else i = foo(i); if (argc < 2) i++; else i = foo(i); if (argc < 3) i++; else i = foo(i); if (argc < 4) i++; else i = foo(i); return i; It gets optimized to just.. return 4; opt -atomic-region-clone -mem2reg -predsimplify -simplifycfg -instcombine .. where -atomic-region-clone is a pass I've

Does LLVM hoist bounds checks out of inner loops? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e