search for: lvi

Hello. This question has come up in https://reviews.llvm.org/D70043 There, i'm teaching ConstantRange how no-wrap flags affect the range of `mul` instruction, with end goal of exploiting this in LVI/CVP. There are certain combinations of ranges and no-wrap flags that result in always-overflowing `mul`. For example, `mul nuw nsw i4 [2,0), [4,0)` always overflows: https://rise4fun.com/Alive/1aK so for such ranges the ideal answer is `empty set`; although it wouldn't be incorrect to return a...

Hi guys, I have an analysis that is able to answer questions like this: given an integer variable, what is the interval of values that this variable can assume during the program's execution? I want to integrate this analysis into LLVM and it seems LVI (Lazy Value Info) is the best place to do this kind of stuff. Can someone give some hints about what I have to do to integrate my analysis into LVI? Best regards, Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/a...

...interface only gives the client information about which values are constants. Is this true? Second, reading the code I see that the ranges are being computed, but I could not tell if this part of the code is already completely done. Would it be possible to print the ranges of the values computed by LVI? Third, besides JumpThreading.cpp is there any other client that uses LVI? I would like to couple my range analysis ( http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.paper.pdf) with the LVI interface, so that is why I am interested on it. Kind regards, Douglas On Mon,...

.... 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 form of CFG limiters in LVI or CVP, so it doesn't seem surprising that large memory use can be easily triggered. This normally also corresponds to very slow compilation, so it addressing it fixes two issues at the same time. A test case can be found in https://llvm.org/bugs/show_bug.cgi?id=10584. The question for me is:...

While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: https://llvm.org/bugs/show_bug.cgi?id=28400 Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this: 1. LVI holds an AssertingVH pointing at a BasicBlock 2. Some other pass ends up deleting that BB (e.g. SimplifyCFG) 3. BOOM Notice that this ends up happening even though SimplifyCFG ultimately invalidates LVI. But that only happens afte...

...interface would support this case. Did you mean synthesizing the INT_MAX constant and then checking specifically for "X s< INT_MAX" using LazyValueInfo::getPredicateAt? At a glance that seems like it would work, but it feels like an odd way of doing it. Initially I was looking at LVI::getConstantRange but its "at the end of the specified block" interface seems too restrictive. The block containing the comparison may end in a conditional br and so surely LVI can't prove anything there. And the block containing the increment/decrement instruction may contain som...

...el Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, January 14, 2016 10:38:10 AM > Subject: Re: [llvm-dev] High memory use and LVI/Correlated Value > Propagation > On Thu, Jan 14, 2016 at 5:57 AM, Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > On Wed, Jan 13, 2016 at 04:28:03PM -0800, Daniel Berlin wrote: > > > > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberge...

...to LLVM Abstract The objective of this work is patch our implementation of range analysis into LLVM. I have a running implementation of range analysis in LLVM, but it is not currently part of the main distribution. I propose to integrate our range analysis implementation into the Lazy Value Info (LVI) interface that LLVM provides. Range analysis finds the intervals of values that may be bound to the integer variables during the execution of programs and is useful in several scenarios: constant propagation, detection of potential buffer overflow attacks, dead branch elimination, array bound chec...

On Wed, Jan 2, 2019 at 1:34 AM Markus Lavin <markus.lavin at ericsson.com> wrote: > To be more specific I am trying to use LVI from inside BasicAA to improve > some cases that turned out to be relevant for our downstream target. > > > > The code is in https://reviews.llvm.org/D55107 and I have problems with a > failing assert in the LazyValueInfoWrapperPass destructor caused by the > fact that LVI is a...

On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > I don't think that arbitrary limiting the complexity of the search is the > right approach. There are numerous ways the LVI infrastructure could be > made more memory efficient. Fixing the existing code to be memory efficient > is the right approach. Only once there's no more low hanging fruit should > we even consider clamping the search. Memory efficiency is only half of the problem. I.e. groonga's...

....llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > I don't think that arbitrary limiting the complexity of the > search is the > > right approach. There are numerous ways the LVI infrastructure > could be > > made more memory efficient. Fixing the existing code to be > memory efficient > > is the right approach. Only once there's no more low hanging > fruit should > > we even consider clamping the search. > >...

...I have a running implementation of range Say "working implementing" instead of "running implementation." > analysis in LLVM, but it is not currently part of the main > distribution. I propose to integrate our range analysis implementation > into the Lazy Value Info (LVI) interface that LLVM provides. Range > analysis finds the intervals of values that may be bound to the > integer variables during the execution of programs and is useful in > several scenarios: constant propagation, detection of potential buffer > overflow attacks, dead branch elimi...

...ranch. When I said it was guaranteed to wrap, I only meant for the range of values that were possible after the first branch. In theory, the CorrelatedValuePropagation pass should have been able to optimize the select. It was able to see that the input to add was in the range [8,14) in the call to LVI->getConstantRange in processBinOp. processCmp skips calling LVI for the select's icmp because the input isn't in the same basic block and isn't a phi. And the call to LVI->getConstant for the select in processSelect didn't return a constant. I think this is because the code ex...

...is now "correct" to obvious clients > > I'm mentioning CVP because it *really* needs to be refactored to use > e-SSA/SSI. The current code is slow, is very limited in scope (w/ somewhat > arbitrary throttling), and is too complicated. > Note that with patches to do LVI in DFS postorder instead of BFS order, it actually should be close to ideal :) If CVP moves forward and queries LVI in RPO order, and LVI is doing PO, it should be as close to O(1) work per LVI call as you can get. Of course, it's still a mess, code wise, but ... -------------- next part ----...

.... The new PM stuff is making excellent progress, and this is actually one of the last things to clean up. On Mon, Aug 8, 2016 at 1:10 AM Sean Silva <chisophugis at gmail.com> wrote: > Thoughts? For the moment I have put in a workaround (r274457) that makes > jump-threading invalidate LVI. > > > Is everybody happy with this workaround? > I wasn't too happy with it, but I had no better suggestion. As the infrastructure matured, what I think is a substantially less horrible workaround is available in the form of what I implemented in r292773. Instead of just working...

...berger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > > I don't think that arbitrary limiting the complexity of the search is the > > > right approach. There are numerous ways the LVI infrastructure could be > > > made more memory efficient. Fixing the existing code to be memory > > efficient > > > is the right approach. Only once there's no more low hanging fruit > > should > > > we even consider clamping the search. > > > &...

Looks like LVI actually does have cases for max and min; would it be better to allow ValueTracking to use range analysis instead? - CL > On Aug 1, 2016, at 8:44 PM, Philip Reames <listmail at philipreames.com> wrote: > >> On 07/29/2016 07:08 PM, Carlos Liam via llvm-dev wrote: >> Hi al...

Hi everyone! I want to clarify the purpose and design of SESES. Thus far, I've characterized it as an LVI mitigation which is somewhat incorrect. SESES was built as a "big hammer." It is intended to protect against many side channel vulnerabilities (Spectre v1, Spectre v4, LVI, etc, etc) even though it was built in response to LVI. For folks protecting against LVI, this is an option for mit...

...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 seemed to be a fair amount of room for > improvement in LVI and ConstantRange. Could you point some out? Thanks Hongbin > > > John > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next...

On Wed, Mar 23, 2011 at 6:24 PM, John Criswell <criswell at illinois.edu> wrote: > > > On 3/23/11 8:06 AM, Douglas do Couto Teixeira wrote: > > > > the execution of a program. Thus, for each integer variable, a range > > analysis determines its lower and upper limits. A very simple range analysis > > > would, for instance, map each variable to the limits