similar to: [LLVMdev] opt and bugs

On 2009-11-19 22:16, John Regehr wrote: > 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

Thanks Duncan and Edwin-- looking at the passes used everyday sounds like the right approach. > Also I think you should also try to test LLVM IR features that are less > often used: > byval, weak linkage, ssp, structs with unusual layout/alignment, vector > operations, > multiple return values, indirectbr, atomic ops, lifetime/invariant > annotations, etc. Well, we are

> 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

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

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

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

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.

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

John Regehr wrote: > Qiuping, > > Have you looked at what has already been done? I would expect that taking > previous work such as this: > > http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.html > > and integrating into current LLVM would be a better idea than starting > over. > This code is publicly available from the SAFECode project (see

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

Is the ABCD pass ready for stress testing? If so, we can do some of this. I guess it would be ready for stress testing if: - it already works fairly well for moderate-sized inputs - someone is willing to act on bug reports Thanks, John Regehr

Hi， John Criswell！ You have said to me that SAFECode had not been maintained for several years, now I have submitted my proposal for updating the SAFCode project to the new LLVM APIs. If you are still interested in the topic and willing to guid my project, I will be very happy. Now I'm waiting for you comments. Here is my proposal:

John-- a couple questions: Can you explain the SAFECode model in a bit more detail? I am getting conflicting information. On one hand, some of the papers describe a system that is primarily designed to hide safety violations. On the other hand, the 2006 ICSE paper that I cited earlier today seems to be talking about catching violations. These are very different goals! What does the code

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

yiqiuping1986 wrote: > Hi， John Criswell！ > You have said to me that SAFECode had not been maintained for several > years, Just to clarify, SAFECode *has* been and *is* maintained (primarily by me). The release_26 branch in the SVN repository works with LLVM 2.6, and mainline is working (with some regressions) with the upcoming LLVM 2.7. You can subscribe to the SVA Commits mailing list

On 28/02/12 17:48, John Regehr wrote: >> void t2(double *x) >> { >> long long a[2]; >> a[0] = 3; >> a[1] = 5; >> *x = * ((double *) a); >> *(x+1) = * ((double *) &a[a[0]-2]); >> } > > Doesn't this code violate the strict aliasing rules? Maybe, but the LLVM IR he showed seems perfectly well defined. Ciao,

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