similar to: [LLVMdev] PredicateSimplifier questions

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

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

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

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

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

On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > >> On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> >>> Let us know if you would like extra eyes on the two PPC failures. >>> Many >>> of us have a lot of experience with C++. :-) Do you know where these >>> allocations are?

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something

On May 26, 2008, at 1:25 AM, Bill Wendling wrote: > On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: >> On May 25, 2008, at 12:58 AM, Bill Wendling wrote: >> >>> Could you try this (massively hacky) patch out to see if it fixes >>> your >>> problem? >>> >>> >> Alas, it didn't fix the problem: >> > Crumbs. > >

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: > Could

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

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

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

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

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

Reid Spencer wrote: If you haven't confirmed your attendance yet, please do so by > responding to this email. I'll be there. Furthermore, I'd like to present the Design and Implementation of the PredicateSimplifier pass, or, "VRP in LLVM". Nick Lewycky

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

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

Hello, I'm starting to play with LLVM today and I've trouble compiling it. I'm working under Windows Vista, with the gcc from Cygwin: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)? The LLVM source tree is from the current SVN trunk. Compilation

Hello, Alain. > I'm starting to play with LLVM today and I've trouble compiling it. > I'm > working under Windows Vista, with the gcc from Cygwin: Oh, this seems to be killer mix :) GCC (at least native mingw32 port) has known problems being running on Vista. > Is LLVM supposed to work with this version of GCC (probably using the > -mno-cygwin option to get a