similar to: [LLVMdev] Question about Value Range Propagation

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

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 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, Andrey, sorry for the delay: I made a page with the code available for download: http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.html Feel free to get it, and if you need some help, I will be happy to tell you how to set the analysis up, in case the explanation in the page is not good. I also have a report describing the implementation here: (

Can't read your paper because the permission is not set. Chuck On 2/25/2011 12:16 PM, Douglas do Couto Teixeira wrote: > Hi, Andrey, > > sorry for the delay: I made a page with the code available for > download: > http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.html >

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

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, Gratian, I did that Summer of Code. I used a different algorithm than Patterson's. It is a constraint system by Su and Wagner, which is more modern, and has some advantages over older works. In particular, it is non-iterative. I found it very hard to compare it with Patterson's analysis, because there is not much description in that paper. However, there is another paper, by

Please unsubscribe me from this list. Sujatha Gurumurthy Staffing Consultant/Talent Advisor UMG - Ultra Mobile Group sujatha.gurumurthy at intel.com US ERP Manager Interested in Employee Referral Program Visit referral.intel.com/ Intel USA Employee Referral Program Group 100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE -----Original Message----- From: llvmdev-bounces at

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

Hi! I'm a student who would like to participate on Google SOC for LLVM, and was thinking about what project to pick. I saw on the "Open projects" page that Value Range Propagation is not implemented and thought about doing it, based on a paper by Patterson (it's also used by GCC). But then I saw that last year someone did a Range Analysis pass that seems to do pretty much the

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

Hello, I wonder if llvm has pure range propagation pass. Is correlated value propagation that one? It seems that it is not directly deals with ranges. Maybe there any passes that simply contain some information about value ranges? Will symbolic value range propagation be done in some time? -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

Hi R, I have a list > class(pp2) [1] "list" > length(pp2) [1] 1244 It is in the below format RIC Trade.Date Close.Price Currency.Code Convertion.Rate New.Price ABCD.SZ 2008/02/29 15.30 CNY 0.1408 2.154240 ABCD.SZ 2008/01/31 15.27 CNY 0.1392 2.125584 ABCD.SZ 2007/12/31 14.88 CNY 0.1371 2.040048

I'm wondering what is the best way to handle constant propagation for complex types in LLVM. For example, my language needs to be able to simplify expressions involving strings by precomputing (in my own constant propagation pass) various external function calls. Here's an example program: ---------------- ; ModuleID = 'LFunction' declare i8* @"set at SS"([5 x

> Is this really true? For example, suppose you know that X is in the range > [1, +inf], and now you calculate Y = 1 / X, then you get that Y is in the > range [0, 1]. But there is no guarantee that Y is really in that range: > since X might have overflowed it might for example be equal to -1, in which > case Y would be equal to -1 too, outside the range [0, 1]. In short, I doubt

Hi everyone, I am very interested in contributing to LLVM project in this year's GSoC. I am new with LLVM, but this is used in the compiler course in my university. So, I am thinking to involve in LLVM development to have a better knowledge of the system. Currently, I am preparing the proposal. One of the project that caught my eyes is "New Transformations and Analysis". Several