search for: overdefin

...ch (or backported, FWIW), if it gets reviewed and there are no substantial problems. #### Background: The current lattice for SCCP doesn't know about `undef`, that is, it's identical to the one described in [1]. There are three lattice states, "Unknown"/"Constant"/"Overdefined" (the first one is what the paper calls "Undefined", but was renamed as "undefined" in LLVM has a different meaning). SCCP (or its interprocedural counterpart) currently consists of two phases: 1) The solver, which implements the algorithm described in the paper. At the...

...P.cpp b/lib/Transforms/Scalar/SCCP.cpp index 8a6be97..45f1241 100644 --- a/lib/Transforms/Scalar/SCCP.cpp +++ b/lib/Transforms/Scalar/SCCP.cpp @@ -908,8 +908,18 @@ void SCCPSolver::visitBinaryOperator(Instruction &I) { } // If something is undef, wait for it to resolve. - if (!V1State.isOverdefined() && !V2State.isOverdefined()) - return; + if (!V1State.isOverdefined() && !V2State.isOverdefined()) { + Constant *L = UndefValue::get(I.getOperand(0)->getType()); + if (V1State.isConstant()) + L = V1State.getConstant(); + Constant *R = UndefValue::get(I.getOp...

...> index 8a6be97..45f1241 100644 > --- a/lib/Transforms/Scalar/SCCP.cpp > +++ b/lib/Transforms/Scalar/SCCP.cpp > @@ -908,8 +908,18 @@ void SCCPSolver::visitBinaryOperator(Instruction &I) { > } > > // If something is undef, wait for it to resolve. > - if (!V1State.isOverdefined() && !V2State.isOverdefined()) > - return; > + if (!V1State.isOverdefined() && !V2State.isOverdefined()) { > + Constant *L = UndefValue::get(I.getOperand(0)->getType()); > + if (V1State.isConstant()) > + L = V1State.getConstant(); > + Constan...

...t;> --- a/lib/Transforms/Scalar/SCCP.cpp >> +++ b/lib/Transforms/Scalar/SCCP.cpp >> @@ -908,8 +908,18 @@ void SCCPSolver::visitBinaryOperator(Instruction &I) >> { >> } >> >> // If something is undef, wait for it to resolve. >> - if (!V1State.isOverdefined() && !V2State.isOverdefined()) >> - return; >> + if (!V1State.isOverdefined() && !V2State.isOverdefined()) { >> + Constant *L = UndefValue::get(I.getOperand(0)->getType()); >> + if (V1State.isConstant()) >> + L = V1State.getConstant(...

...rating-[un?]signed-add` range already returns empty set in similar cases, here we 'need' to model it explicitly. (as it is seen in the patch, the modelling is reasonably straight-forward) As it was pointed out in the review, currently, LVI does not make use of empty-sets, and maps them to `overdefined`: https://godbolt.org/z/N3KggA So the question is: considering the fact that LVI would not make use of such empty-set knowledge, does that mean we shouldn't bother doing that extra analysis in ConstantRange, thus avoiding the compile time cost of said modelling? Right now i'm thinking w...

...it gets reviewed and there are no > substantial problems. > > #### Background: > The current lattice for SCCP doesn't know about `undef`, that is, it's > identical to the one described in [1]. There are three lattice states, > "Unknown"/"Constant"/"Overdefined" (the first one is what the paper > calls "Undefined", but was renamed as "undefined" in LLVM has a > different meaning). > > SCCP (or its interprocedural counterpart) currently consists of two phases: > 1) The solver, which implements the algorithm describ...

...And both of > these are bad because you're making a non-monotonic transition? Yes > Given > this, I'm not sure what prevents the bad transform from happening even > if we have separate Unknown and Undef states. You can always get *out* of the bad transform by dropping to overdefined if you discover it doesn't work. The question is more one of "what is the optimal time to try to figure out a constant value that works". If you drop too early, you have to go overdefined when you may have been able to figure out a constant to use to replace the undef. > >...

...r of the algorithm, this could appear super linear in running time. If you have found a case that involves many steps for each variable in the lattice, one principled fix would be to bound the number of constant range refinements allowed. e.g. If you updated the constant range 5 times, drop to overdefined. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160114/38ec9878/attachment.html>

...instead staying as a GetElementPtrInst. I thought this might be because the optimizer is being conservative about correctness, but that the lattice must still show it as underdefined -- but obviously as I haven't looked at the lattice directly, I haven't verified that yet. Maybe it becomes overdefined as the constant can't be resolved, and I should just fix the SCCP pass? Nick

...hange the ranges (they only get *better*, however). > So you may need to do this until they fall all the way down the > lattice. > This means you may repeat this lattice height number of times. What is the height of the lattice here? I understand that it goes from top -> defined -> overdefined, and that's three, but defined is not itself one state. Because it is tracking integer ranges, those ranges could undergo 2^#bits refinements in the worst case (thus making the lattice height quite large), no? Thanks again, Hal > CVP as currently implemented tries to be very lazy. The c...

Hi Daniel, On Fri, Dec 30, 2016 at 10:55 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> Right, but we are talking about "when, in the intermediate state, can i >> transform an undef to a different value". >> >> Remember you can only go down the lattice. So you can't make undef >> constant, and then discover it's wrong, and go back up :)

...> about correctness, but that the lattice must still show it as > underdefined -- but obviously as I haven't looked at the lattice > directly, I haven't verified that yet. Yup, if there is a load from a memory location on the stack, SCCP won't touch it: it will assume it is overdefined. > Maybe it becomes overdefined as the constant can't be resolved, and I > should just fix the SCCP pass? I'd suggest fixing this in the instcombine pass. This isn't something that the 'conditionalness' of SCCP adds value for, so doing it in a simpler place is bette...

...in <dberlin at dberlin.org> > wrote: > >> > >>> Is there a case in your algorithm in which treating an > >>> unknown as an undef will be a problem? > >>> > > Yes, if you try to optimize undefs in any way, no if you move them to > > overdefined :) > > > > IE given phi [a, undef, undef, undef] > > > > with just as many back edges, you will visit this node 4 times. > > > > If you start out with > > > > phi [a, undef, undef, undef], you may think "I know, i will make these > > und...

...able to (my unproven conjecture) start from "map each > instruction to undef", making the "unknown" element superfluous. > See the email i just sent. Your scheme would work if you didn't want to optimize undef, because you'd just make meet (anything, undef) -> overdefined. It's the "we want to fill in values for undef" that makes it so you need to know when you can actually do that. (and as mentioned, you don't need a separate post-resolver to do *what we do now*, and so far, it has just been a source of bugs :() -------------- next part --------...

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

...ec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> >>> Is there a case in your algorithm in which treating an >>> unknown as an undef will be a problem? >>> > Yes, if you try to optimize undefs in any way, no if you move them to > overdefined :) > > IE given phi [a, undef, undef, undef] > > with just as many back edges, you will visit this node 4 times. > > If you start out with > > phi [a, undef, undef, undef], you may think "I know, i will make these > undef's a". > > So you move every...

...#39;re making a non-monotonic transition? > > Yes > >> >> Given >> this, I'm not sure what prevents the bad transform from happening even >> if we have separate Unknown and Undef states. > > > You can always get *out* of the bad transform by dropping to overdefined if > you discover it doesn't work. > The question is more one of "what is the optimal time to try to figure out > a constant value that works". > If you drop too early, you have to go overdefined when you may have been > able to figure out a constant to use to replac...

> > > Is there a case in your algorithm in which treating an >> unknown as an undef will be a problem? >> >> Yes, if you try to optimize undefs in any way, no if you move them to overdefined :) IE given phi [a, undef, undef, undef] with just as many back edges, you will visit this node 4 times. If you start out with phi [a, undef, undef, undef], you may think "I know, i will make these undef's a". So you move everything to value phi [a, a, a, a] But remember, yo...

...g> >> wrote: >> >> >> >>> Is there a case in your algorithm in which treating an >> >>> unknown as an undef will be a problem? >> >>> >> > Yes, if you try to optimize undefs in any way, no if you move them to >> > overdefined :) >> > >> > IE given phi [a, undef, undef, undef] >> > >> > with just as many back edges, you will visit this node 4 times. >> > >> > If you start out with >> > >> > phi [a, undef, undef, undef], you may think "I know,...

...vely assuming that the *nix > uidNumber/gidNumber Samba mapped the end user to > would behave exactly the same whether they were a > Samba user or were logged on locally. ... After a year I think I understand well enough to answer my own question (of course I may be wrong anyway:-): The overdefined term ACL may refer to _either_ Windows file permissions (including the NT variant) _or_ the Linux/Posix file permissions extension. In the Samba context questions about "ACL"s can be indeterminate and often elicit answers from the other point of view. At root, Samba does everything i...