search for: predsimplify

...> 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 wrote predsimplify as I was learning about compiler theory. It's pretty dumb in the sense that it spends lots of time analysing things that will never be used, and despite being the slowest pass in LLVM I haven't seen it improve run-times in a nightly test. > Also, a colleague and I (we both teach adva...

...ition. (Yes, that is as silly as it sounds.) I >>> tested that, and it did optimize as expected. It's essentially working >>> around a deficiency in the optimizer around path constraints. >>> >> > Once upon a time, there was an optimization for this called predsimplify. > I believe Nick can tell you a long, glorious, tragic tale about its life > and ultimate death. > Okay, gather 'round the fire. ;-) Predsimplify was the first optimization pass I tried to write, to fix PR807. The basis was that it would propagate properties (icmp's between two...

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

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 just leave them on at O3? Based on the discussion around your simple condition propagation pass, it seemed predsimplify did delete de...

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 single element."); > > > > If I ig...

...oo, though we were mostly > interested in Patterson's approach (i.e. not connected with SSI form). It > would be great if you can share the code nevertheless. 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. Ciao, Duncan.

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

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

...X is replaced by Y everywhere in the true >>> destination >>> (likewise if it is "X != Y" then X is replaced by Y everywhere in the false >>> destination). Completely untested for correctness! >> >> Not to discourage you, but you're reinventing predsimplify. >> >> What PS did was find branches (or switches) where the target block was >> uniquely dominated by a single case, then assign %cond = true/false (or >> %switchval = const) and then walk up propagating that condition upwards >> (ie., if %cond = and i1 %a, %b the...

...has > the form "X == Y" then X is replaced by Y everywhere in the true > destination > (likewise if it is "X != Y" then X is replaced by Y everywhere in the false > destination). Completely untested for correctness! Not to discourage you, but you're reinventing predsimplify. What PS did was find branches (or switches) where the target block was uniquely dominated by a single case, then assign %cond = true/false (or %switchval = const) and then walk up propagating that condition upwards (ie., if %cond = and i1 %a, %b then %a and %b are true, and if %a = icmp eq i3...

...ot;X == Y" then X is replaced by Y everywhere in the true >> destination >> (likewise if it is "X != Y" then X is replaced by Y everywhere in the false >> destination). Completely untested for correctness! > > Not to discourage you, but you're reinventing predsimplify. > > What PS did was find branches (or switches) where the target block was > uniquely dominated by a single case, then assign %cond = true/false (or > %switchval = const) and then walk up propagating that condition upwards > (ie., if %cond = and i1 %a, %b then %a and %b are true...

...ning random combinations of passes using opt, which ones should we leave out, because you folks don't want to hear that they're wrong? For example, the other day I learned that ABCD is not yet ready for this sort of testing. A while ago someone on the list said something similar about predsimplify (though it looks like that pass has disappeared from the tree?). Also I'd appreciate some advice about probabilities for each pass. For example, it seems like a lot of passes will have little to do if Mem2Reg doesn't run, so perhaps that pass should get >0.5 probability of running....

...ld 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 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. >> >&...

...ather than 'load'ing them over again at each use. This eliminates the dependency on alias analysis (at the cost of increased register pressure). With that out of the way, it becomes a matter of building a pass pipeline which either hoists or eliminates the checks. opt -mem2reg -gvn -predsimplify -licm -dce -simplifycfg may be a starting point for elimination. Any of the passes in lib/ Transforms/Scalar which include the string 'SCEV' may be helpful for hoisting. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

...nfo about vars (e.g. the set of possible values for a given vars, etc..) - implement that interface in several ways with different tradeoffs of preciseness vs speed (e.g. range analysis, value set tracking, path sensitive or not, interprocedural, etc..) I believe this could reuse some code from PredSimplify and hopefully make it a very simple pass (as much of the work would then be hidden in the value tracking analysis). Having this sort of readily available analysis would allow us to build other optimization more easily. I've already a few ideas in mind (I've implemented one of them, but...

...mple 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 written (-mem2reg to clean up the PHIs I reg2mem'd). My pass inserts a custom atomic_begin instruction and a couple intrinsics to help start/rollback a region of code. The optimized .ll code is roughly.. entry: ; st...

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