similar to: [LLVMdev] value tracking

Nuno Lopes wrote: > 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

On Sat, Mar 3, 2012 at 5:26 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Xin, > >> It seems to me that LLVM does not do too much on value range analysis. >>   i.e. what are the value constraints on a variable at a given point in >> the program. The closest thing i can find is the ValueTracking API, >> which can do some simple analysis on the value of a

Hi, I have two questions about optimizations performed by llvm. Consider these simple functions: int x(int b) { return b?4:6; } int y() { return x(0); } int x2() { return 5; } int y2() { return x2(); } the optimized bitcode (with clang + opt -std-compiler-opts) is: define i32 @y(...) nounwind { entry: ret i32 6 } define i32 @y2(...) nounwind { entry: %call = call i32 (...)* @x2( ) ;

Dear R-Users, I would like to know whether it is possible to draw several stacked barplots (i.e. side by side on the same sheet)... my data look like : Cond1 Cond1' Cond2 Cond2' Compartment 1 11,81 2,05 12,49 0,70 Compartment 2 10,51 1,98 13,56 0,85 Compartment 3 1,95 0,63 2,81 0,22 Compartment 4 2,08 0,17

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 everyone, I posted some questions related to implementing inference of nsw/nuw flags based on known icmp results to Bug 30428 ( https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended that I engage a wider audience by coming here. The minimal context is the following, please see the bug report for more detail: > 1. If (X s< Y), then both X + 1 and Y - 1 are nsw. > 2.

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

On Thu, Sep 4, 2008 at 8:39 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt

Dear Colleagues, Our group is also working on implementing the use of R for pharmacokinetic compartmental analysis. Perhaps I have missed something, but > fit <- nls(noisy ~ lsoda(xstart, time, one.compartment.model, c(K1=0.5, k2=0.5)), + data=C1.lsoda, + start=list(K1=0.3, k2=0.7), + trace=T + ) Error in eval(as.name(varName), data) : Object

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

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

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

I'm having trouble understanding how APInts should be used. The APInt documentation states that it 'is a functional replacement for common case unsigned integer type', but I'm not seeing this because the internal logic is that the value is always treated as negative if the most significant bit is set. I'm interested in an add or sub that could be using a negative value. 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

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 LLVM developers, I am implementing Loong Language[1] using Clang FrontEnd and LLVM MiddleEnd. I add `wire`[2] Builtin Type, and clang is able to parse very small testcase fulladder[3] but failed to work for 10+K loc RISCV E203 project[4]: Loongson clang version 7.0.0 (git at github.com:Loong-Language/loong-clang.git 8f7e826f27abbe12ea08d9563490298c38d3adc1) (git at

Hi Phillip, I've been looking into the Capture Tracking Improvements and I was wondering if there was any research/documentation that you know of that I could use as background reading? Many thanks, Scott

Good day, LLVMers! We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: http://llvm.org/pre-releases/3.0/rc3/ for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your projects, and let us know if you find any regressions from the 2.9 release. Please keep

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