search for: lazyvalueinfo

Hi, Both LazyValueInfo and ScalarEvolution can calculate a constant range for an LLVM Value. I found that some times they do not agree, may be I interpreted them incorrectly For example in the following IR: bb85: ; preds = %bb85, %bb73 %tmp86 = phi i32 [ 1, %bb73 ], [ %tmp9...

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantR...

Thanks, maybe we could use ScalarEvolution in LazyValueInfo if it is available? On Mon, Jul 24, 2017 at 1:44 PM, John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Since they are different static analyses there's no reason to expect them > to agree, but they should both be conservative. In other words, if you like > you can...

On Mon, Jul 24, 2017 at 2:29 PM, John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 7/24/17 3:16 PM, Hongbin Zheng via llvm-dev wrote: > >> Thanks, maybe we could use ScalarEvolution in LazyValueInfo if it is >> available? >> > > This should be fairly easy to try, if you want to propose a patch and run > some experiments. The question is whether the benefit in terms of improved > optimization power is worth the compile-time cost. Ok Also, the last time I looked, there...

Hi, I am working on some changes to LazyValueInfo and I wanted to see how it was used in existing passes. Currently I can see that Jump Threading and Correlated Value Propagation are the 2 passes that use LazyValueInfo. However on the LLVM docs page of passes (http://llvm.org/docs/Passes.html <http://llvm.org/docs/Passes.html>), Correlated...

...se see the bug report for more detail: >> >> > 1. If (X s< Y), then both X + 1 and Y - 1 are nsw. >> > 2. If (X u< Y), then both X + 1 and Y - 1 are nuw. > If this is the only case you want to support, this sounds like a fairly > straight forward extension to the LazyValueInfo analysis. In > particular, take a look at getValueFromICmpCondition. I'd be happy to > help review a patch here once you've got something working. > > The basic idea would be that (X s<Y ) implies X s< INT_MAX since Y must > be INT_MAX or smaller and X is less than th...

Hi all. Guys in accordance to PR1255 I need to add case-ranges support for passes listed in subject. Who can review some of these passes in nearest future? Thanks! -Stepan.

Hi: In my in-house transform passes I needs to properly lower Switch/Invoke and PhiNodes, prior to LLVM9 I just call createLowerSwitchPass() and run it. However in LLVM9 doing this would assert out with error message: &nbsp;&nbsp; Assertion failed: (Resolver &amp;&amp; "Pass has not been inserted into a PassManager object!"), function getAnalysis, file

After writing a simple FPRange, I've hit a stumbling block. I don't know what LLVM code should be extended to use it. I was initially thinking of extending LazyValueInfo, but it appears to be used for passes that don’t address the case that I need for Julia. I’m now wondering if I’m better off extending SimplifyFCmpInst to handle the few cases in question instead of trying to be more general. Here’s an example case for Julia where a trivially true domain check sh...

Thanks for the pointers. Looks like LazyValueInfo has the sort of infrastructure I had in mind. LVILatticeVal could be extended to floating point. (The comment "this can be made a lot more rich in the future" is an invitation :-). I'm thinking a simple lattice would address most cases of interest for floating-point checks. The l...

On Mon, Aug 7, 2017 at 2:14 AM, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am trying to print it like this (maybe here is smth wrong?) > > > LazyValueInfo &LV = getAnalysis<LazyValueInfoWrapperPass>().getLVI(); > DominatorTree &DT = > getAnalysis<DominatorTreeWrapperPass>().getDomTree(); > LV.printLVI(F, DT, llvm::outs()); The value analysis in llvm is lazy (hence, LVI), so you're trying to print an empty cac...

...ruction : %cmp = icmp slt > i32 %i.03, 99, > that %i.03 = phi i32 [ 0, %entry ], [ %inc, %for.body ] has > a range [0, 99]? > > And what is then a correct way to get such an info, that you sent ( with > more specified ranges)? ...seems that appropriate method for it is not in > LazyValueInfo class. > > 2017-08-07 11:34 GMT+02:00 Davide Italiano <davide at freebsd.org>: > >> On Mon, Aug 7, 2017 at 2:14 AM, Anastasiya Ruzhanskaya via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > I am trying to print it like this (maybe here is smth wrong?)...

...bison" <arch.robison at intel.com> > To: "Philip Reames" <listmail at philipreames.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, January 8, 2015 12:54:32 PM > Subject: Re: [LLVMdev] Floating-point range checks > > > Thanks for the pointers. Looks like LazyValueInfo has the sort of > infrastructure I had in mind. LVILatticeVal could be extended to > floating point. (The comment “this can be made a lot more rich in the > future” is an invitation :-). I’m thinking a simple lattice would > address most cases of interest for floating-point checks....

...= createLowerSwitchPass(); lower->runOnFunction(*f); But it will crash when running lower->runOnFunction(*f) in llvm-9. I was using this method in llvm-8 and it worked fine. It seems the crash happens at the first line of the LowerSwitch::runOnFunction(Function &F) in the newer llvm: LazyValueInfo *LVI = &getAnalysis<LazyValueInfoWrapperPass>().getLVI(); //crashed here I can't figure out why this usage cause the compiler to crash? Am I calling function pass wrong? Thank you for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

The Julia language implements sqrt(x) with conditional branch taken if x<0. Alas this prevents vectorization of loops with sqrt. Often the argument can be proven to be non-negative. E.g., sqrt(x*x+y*y). Is there an existing LLVM pass or analysis that does floating-point range propagation to eliminate such unnecessary checks? Arch D. Robison Intel Corporation -------------- next part

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.

...To: "Philip Reames" <listmail at philipreames.com>, >>> llvmdev at cs.uiuc.edu >>> Sent: Thursday, January 8, 2015 12:54:32 PM >>> Subject: Re: [LLVMdev] Floating-point range checks >>> >>> >>> Thanks for the pointers. Looks like LazyValueInfo has the sort of >>> infrastructure I had in mind. LVILatticeVal could be extended to >>> floating point. (The comment “this can be made a lot more rich in >>> the >>> future” is an invitation :-). I’m thinking a simple lattice would >>> address most case...

...unction(*f); >> >> But it will crash when running lower->runOnFunction(*f) in llvm-9. >> I was using this method in llvm-8 and it worked fine. It seems the crash happens at the first line of the LowerSwitch::runOnFunction(Function &F) in the newer llvm: >> >> LazyValueInfo *LVI = &getAnalysis<LazyValueInfoWrapperPass>().getLVI(); //crashed here >> >> I can't figure out why this usage cause the compiler to crash? Am I calling function pass wrong? >> >> Thank you for your help. > ______________________________________________...

Hi all, with the current trunk I have two major cases where clang needs more than 2GB memory for compiling programs with -O2. One is related to GVN and MemoryDependenceAnalysis and has a pending patch. The other is related to the Correlated Value Propagation and Lazy Value Information cache. Attached is a heap profile for one of the relevant test cases. Looking at the sources, I don't see any

...lt;listmail at philipreames.com>, > >>> llvmdev at cs.uiuc.edu > >>> Sent: Thursday, January 8, 2015 12:54:32 PM > >>> Subject: Re: [LLVMdev] Floating-point range checks > >>> > >>> > >>> Thanks for the pointers. Looks like LazyValueInfo has the sort of > >>> infrastructure I had in mind. LVILatticeVal could be extended to > >>> floating point. (The comment “this can be made a lot more rich in > >>> the future” is an invitation :-). I’m thinking a simple lattice > >>> would addres...