search for: correlatedvaluepropag

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 Value Propagation is not mentioned as a pass. Does

...eater = n1 > n2; if (greater && b) { foo(); if (n1 == n2) { return false; // unreachable } } return true; } In this case, simplifycfg doesn't go wild merging everything into a single branch-free expression and so we don't get it. CorrelatedValuePropagation doesn't get this because its processCmp is quite weak (it bails out if one operand isn't a constant). JumpThreading is the only other pass that uses LazyValueInfo and it can't fold this since it can't thread a jump around the side-effecting `foo()` call. I'm not familiar w...

...o(); > > if (n1 == n2) { > return false; // unreachable > } > } > return true; > } > > In this case, simplifycfg doesn't go wild merging everything into a single > branch-free expression and so we don't get it. > > > CorrelatedValuePropagation doesn't get this because its processCmp is > quite weak (it bails out if one operand isn't a constant). JumpThreading is > the only other pass that uses LazyValueInfo and it can't fold this since it > can't thread a jump around the side-effecting `foo()` call. > &gt...

...gt; return false; // unreachable >> } >> } >> return true; >> } >> >> In this case, simplifycfg doesn't go wild merging everything into a >> single branch-free expression and so we don't get it. >> >> >> CorrelatedValuePropagation doesn't get this because its processCmp is >> quite weak (it bails out if one operand isn't a constant). JumpThreading is >> the only other pass that uses LazyValueInfo and it can't fold this since it >> can't thread a jump around the side-effecting `foo()` ca...

...tting around than they are passing along. For example, instcombine has a DomTree and AssumptionCache that are required, but it doesn't pass them to SimplifyBinOp in a bunch of cases. JumpThreading has TLI but doesn't pass it to SimplifyCmpInst. CVP at least admits it has a problem: "CorrelatedValuePropagation.cpp: // FIXME: Provide TLI, DT, AT to SimplifyInstruction. CorrelatedValuePropagation.cpp: if (Value *V = SimplifyInstruction(P, DL)) { " (This is because it uses LVI, which requires those things, but it doesn't ask for them itself) Assuming this is not deliberate, it would seem to...

...able >>> } >>> } >>> return true; >>> } >>> >>> In this case, simplifycfg doesn't go wild merging everything into a >>> single branch-free expression and so we don't get it. >>> >>> >>> CorrelatedValuePropagation doesn't get this because its processCmp is >>> quite weak (it bails out if one operand isn't a constant). JumpThreading is >>> the only other pass that uses LazyValueInfo and it can't fold this since it >>> can't thread a jump around the side-effectin...

...nstcombine does the same thing to it if you use -O0 with clang > I believe this is because LLVM does not recognize that meeting path > conditions like, for example, X && Y logically means that X is true and Y > is true. > Yes it does. See both GVN's propagateequality and correlatedvaluepropagation, among other things :) In this case, simplifycfg +instcombine will do it The new predicate support i'm building for GVN will also do it. > > I'm interested in creating a patch to remedy this; is there a file or > function I should look at? > > Thanks in advance. >...

...>> } >>>> return true; >>>> } >>>> >>>> In this case, simplifycfg doesn't go wild merging everything into a >>>> single branch-free expression and so we don't get it. >>>> >>>> >>>> CorrelatedValuePropagation doesn't get this because its processCmp is >>>> quite weak (it bails out if one operand isn't a constant). JumpThreading is >>>> the only other pass that uses LazyValueInfo and it can't fold this since it >>>> can't thread a jump around the s...

Hi all, Consider this C code: #include <stdbool.h> bool func(int n1, int n2, bool b) { bool greater = n1 > n2; if (greater && b) { if (n1 == n2) { return false; // unreachable } } return true; } The line marked unreachable cannot be reached, however currently LLVM does not optimize it out. I believe this is because LLVM does not

...ive. 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 some later information that LVI can prove at the end of the block, but is not true at the instruction? CorrelatedValuePropagation and JumpThreading appear to be the only transformation passes making use of LVI at the moment, and that's probably something we don't want to change. This kind of nsw/nuw flag inference doesn't really fit in either, but CVP is definitely the closer match and it should be possib...

...ap. But past that and up to (and > including in the original source code) 13, it will wrap yes. > But the value can't be [0,7] due to the earlier branch. 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...

Hi, I am interested in applying to LLVM as part Google Summer of Code 2015. I have been going through LLVM code since about 4 months now, and while going though mailing list discussions I found particular interest in the point raised by Arch Robinson in January about the development of a floating point range check pass in LLVM. I have been in touch with Arch as well as Hal Finkel about this and

...FG InstCombine Early Loop Opts { LoopSimplify Rotate (when obvious) Full-Unroll (when obvious) } SROA-2 InstCombine GVN Reassociate Generic Loop Opts { LICM (Rotate on-demand) Unswitch } SCCP InstCombine JumpThreading CorrelatedValuePropagation AggressiveDCE } } IR optimizations that require target information or destructively modify the IR can run in a separate pipeline. This helps make a more a clean distinction between passes that may and may not use TargetTransformInfo. TargetTransformInfo encapsultes legal types and oper...

...us) > Full-Unroll (when obvious) > } > SROA-2 > InstCombine > GVN > Reassociate > Generic Loop Opts { > LICM (Rotate on-demand) > Unswitch > } > SCCP > InstCombine > JumpThreading > CorrelatedValuePropagation > AggressiveDCE > } > } > I'm a bit late to this, but the examples of the "generic loop opts" above are really better left until later. They have a potential to obscure the code and make other loop optimizations harder. Specifically, there has to be a pla...

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

Hi guys, I am trying to figure out how to use your Lazy Value Info pass, but I am having some questions. First, it seems that the implementation contains infra-structure to deal with range intervals, but the main 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

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

...It will take place on February 5th 2017 in Brussels. ## On the mailing lists * Davide Italiano has presented a [summary analysis of how LLVM's middle-end has been getting slower over the past 6 months](http://lists.llvm.org/pipermail/llvm-dev/2016-December/108279.html). InstCombine, GVN, and CorrelatedValuePropagation are amongst the most costly passes on Davide's experiments. Daniel Berlin had an [interesting response](http://lists.llvm.org/pipermail/llvm-dev/2016-December/108300.html) to the observation that GCC seems to use more sophisticated algorithms (or at least, its source references more papers...

Hi All, We have recently found some optimization opportunities created by replicating code into branches in order to enable optimization. In general, the optimization opportunity we are pursuing is like the following. Given pseudo-code: // block A if (some condition) // block B // block C If it can be efficiently proven that some portion of block C can be simplified had control flow not