search for: propagateequality

Hello Sanjoy, Yep, combining it with propagateEquality of pointers may raise problem. :\ However I believe propagateEquality should be fixed properly, and adding psub also suggests a solution for that. :) It is sound to replace a pointer with another if subtraction of them is 0: a = malloc() free(a) b = malloc() // Assume b == a numerically if ((psu...

Sure On Mon, Jul 4, 2016, 9:40 AM Carlos Liam <carlos at aarzee.me> wrote: > It looks like there's already something similar in PropagateEquality which > eg X >= Y == true and replaces X < Y == false, which is somewhat similar - > could I base an addition off of that? > > > - CL > > On Jul 3, 2016, at 7:13 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > It's going to be really hard to do some...

...on(Instruction *I) { BasicBlock *Parent = BI->getParent(); bool Changed = false; - Value *TrueVal = ConstantInt::getTrue(TrueSucc->getContext()); + Value *TrueVal = ConstantInt::getTrue(BranchCond->getContext()); BasicBlockEdge TrueE(Parent, TrueSucc); Changed |= propagateEquality(BranchCond, TrueVal, TrueE); - Value *FalseVal = ConstantInt::getFalse(FalseSucc->getContext()); + Value *FalseVal = ConstantInt::getFalse(BranchCond->getContext()); BasicBlockEdge FalseE(Parent, FalseSucc); Changed |= propagateEquality(BranchCond, FalseVal, FalseE); Any oth...

It's going to be really hard to do something sane in the current infrastructure. Its possible, but it would also be slow. You would have to go looking at uses of variables compared in predicates in PropagateEquality and if the uses appear in a comparison that is dominated by the true or false edge of the existing predicate, see if it tells you something about the dominated one. On Mon, Jul 4, 2016, 8:23 AM Carlos Liam <carlos at aarzee.me> wrote: > That seems ominous; should I not bother? > &gt...

PropagateEquality in gvn.cpp However, if you are going to do it, remember the goal is to make the code simpler and easier, not just pile on to the current mess to catch more cases :) On Mon, Jul 4, 2016, 7:51 AM Carlos Liam <carlos at aarzee.me> wrote: > Where would I look to change the equality propaga...

...lock *Parent = BI->getParent(); > bool Changed = false; > > - Value *TrueVal = ConstantInt::getTrue(TrueSucc->getContext()); > + Value *TrueVal = ConstantInt::getTrue(BranchCond->getContext()); > BasicBlockEdge TrueE(Parent, TrueSucc); > Changed |= propagateEquality(BranchCond, TrueVal, TrueE); > > - Value *FalseVal = ConstantInt::getFalse(FalseSucc->getContext()); > + Value *FalseVal = ConstantInt::getFalse(BranchCond->getContext()); > BasicBlockEdge FalseE(Parent, FalseSucc); > Changed |= propagateEquality(BranchCond, F...

...opt -simplifycfg -instcombine 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? > &g...

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

Hi Jianfei Hu, the GVN pass does something like this in the logic around GVN::propagateEquality. If in your example it was if a == 2 // BasicBlock A then then it replaces all occurrences of a with 2 in BasicBlock A. For this it needs to understand which basic blocks can only be reached via this conditional edge "a == 2". Ciao, Duncan. > Hello All, > > I want to...

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

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

I found a case where GVN seems to miscompile an OpenCL program. What I am trying to figure out is given a bitcode file, how can I reduce it to a simpler case with bugpoint when I don't have a valid reference compiler available. Thanks for any tips, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL:

...son in > >> LoopUnswitch may regress other benchmarks. > > > > Any other thoughts on a more minimal fix? > > I can't think of any good answers here. > > The semantic we want is "branching on poison or undef is undefined > behavior" (which lets us do propagateEquality). Given that, we could > be clever about implementing isGuaranteedNotToBeUndefOrPoison; for > instance if we have: > > do { > if (a != b) { > ... > } > } while (...); > > then we can use post-domination to prove that "a != b" is not undef > (other...

...hmarks. >>> > >>> > Any other thoughts on a more minimal fix? >>> >>> I can't think of any good answers here. >>> >>> The semantic we want is "branching on poison or undef is undefined >>> behavior" (which lets us do propagateEquality). Given that, we could >>> be clever about implementing isGuaranteedNotToBeUndefOrPoison; for >>> instance if we have: >>> >>> do { >>> if (a != b) { >>> ... >>> } >>> } while (...); >>> >>> then we c...

On Mon, Jul 17, 2017 at 11:18 AM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Mon, Jul 17, 2017 at 10:32 AM, Xinliang David Li <davidxl at google.com> > wrote: > > The issue blocks another optimization patch and Wei has spent huge > amount of > > effort isolating the the bootstrap failure to this same problem. I agree > >

...can detect when they've been moved to make sure they are still valid if need me. 4. They could be updated pretty easily if we wanted With one real downside: 5. We modify the IR in an analysis to do so :( The main user at the moment is NewGVN, which uses it to do the equivalent of GVN's propagateEquality. I'd be happy to make it a utility called from NewGVN instead of an analysis. A number of folks online and off asked me to make it usable for others, so i did that :) Some folks want to use it to cleanup existing passes (EarlyCSE, etc), some want to use it in new passes. FWIW: A number of alt...

...ny other thoughts on a more minimal fix? >> >>> >> >>> I can't think of any good answers here. >> >>> >> >>> The semantic we want is "branching on poison or undef is undefined >> >>> behavior" (which lets us do propagateEquality). Given that, we could >> >>> be clever about implementing isGuaranteedNotToBeUndefOrPoison; for >> >>> instance if we have: >> >>> >> >>> do { >> >>> if (a != b) { >> >>> ... >> >>> }...

...>>>> >>> >>>> >>> I can't think of any good answers here. >>>> >>> >>>> >>> The semantic we want is "branching on poison or undef is undefined >>>> >>> behavior" (which lets us do propagateEquality). Given that, we could >>>> >>> be clever about implementing isGuaranteedNotToBeUndefOrPoison; for >>>> >>> instance if we have: >>>> >>> >>>> >>> do { >>>> >>> if (a != b) { >>>>...

...e is a direct successor of the branch, such that the edge to that use is critical. In any case, this is also precisely the problem that splitting critical edges resolves, and if you use break-crit-edgse on the above, you get right answers all the time :) Note also that the thing that we replace, propagateEquality in GVN, also restricts itself to single predecessors, and simply attempts to propagate directly into critical phi node uses to avoid the issue (which we can't do since NewGVN is an analysis followed by an eliminator). So yes, we can fix this case if we need to. > > - For a function/i...

Hello All, I want to dertermine whether a basicblock is in a conditional branch. such as, //============================= if a > 2 // BasicBlock A then BasicBlock B endif BasicBlock C //============================= What I want to identify is BasicBlock B, which is in a condtional block. but C is not. In other words, I want to distinguish BasicBlocks that * must * be executed and that