similar to: Adding Extended-SSA to LLVM

On Sun, Feb 5, 2017 at 12:25 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi Daniel, > > Many thanks for working on this! > SSI/e-SSA is the only way I'm aware of for doing efficient sparse > analyses, so I'm definitely in favor of adding support for it in LLVM! > > I read the discussion so far and did a cursory review of the patches, and > I have just a

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>

The current gvn equality propagation is not powerful enough to get this because it doesn't try to infer values in predicates based on other predicates, so it never realizes a>b -> a !=b in a useful way. It otherwise would get this On Thu, Jun 30, 2016, 7:41 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev <

Maybe. It may not fix it directly because you never use %1 or %2 again. I haven't looked to see how good the lookup is. On Fri, Jun 10, 2016, 3:45 PM Josh Klontz <josh.klontz at gmail.com> wrote: > Thanks Daniel, with that knowledge I think I can at least work around the > issue in my frontend. > > Ignoring GVN for a second though, and just looking at Early CSE, it seems

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

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

On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 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 > } >

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 propagation? > > > - CL > > On Jun 30, 2016, at 11:45 PM, Daniel Berlin

On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Consider this C code: >> >> #include <stdbool.h> >> >> bool func(int n1, int n2, bool b) { >>

As of llvm 3.8, the early CSE pass seems to remove llvm.assume intrinsics. Is this the expected behavior? I've attached as small-ish example of this happening in my production code. $ opt -early-cse before-early-cse.ll -S > after-early-cse.ll Note the use of the assume intrinsic indicating that the loaded value %channels equals 3. In a later pass I replace the load instruction with

Yeah, that change is completely unrelated, that is about correctness, this is about optimization. I'm working on a proposal to just fix assume at some point to deal with the former issue. The problem with this testcase is that all the ways assume is propagate expect the variable in the assume to later be used. <This is the main way assume constants are propagated> bool

Hi, we would like to propose a new Global Value Numbering pass in LLVM. The ideas/code are from Daniel Berlin (with a minor overhaul/splitting into submittable patches from me). The code has been around for a while (2012 or before), and we think it's getting ready to be committed upstream. ### Motivation To put things into context: my personal motivation for having a new GVN/PRE algorithm

On Sun, Feb 5, 2017 at 3:41 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Thanks for the answers! The plan makes sense to me. > > Regarding phis, what about diamonds, e.g.: > > > define i32 @f(i32 %x) { > br .., label %bb0, label %bb1 > bb0: > %cmp = icmp sge i32 %x, 0 ; x > 0 > br i1 %cmp, label %bb2, label %bb3 > bb1: > %x2 = add nsw

This can't be an instsimplify though? The values we want in these cases do not exist already: %res = or i8 %b, %a %res = or i1 %cmp, %c On Thu, Jul 13, 2017 at 5:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, Jul 13, 2017 at 2:12 PM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> We have several optimizations in InstCombine

Hi Nick, I checked in something towards (1) yesterday -- http://reviews.llvm.org/D6748 I was under the impression that (2) is exactly the kind of predicate ScalarEvolution::isKnownPredicate is designed to solve (using isImpliedCondXXX or something like that). Is there a reason to prefer GVN over that? On Wed, Jan 7, 2015 at 10:06 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Sanjoy

Hi, Nikita pointed me to an issue in the full restrict patches, related to name mangling used for llvm-ir functions (See [0, 3]). The problem is the following: Given: %0 = type { i32 } %1 = type { i32 } Creating an intrinsic @llvm.FOO that accepts 'a pointer to %0' cannot be distinguished from the intrinsic accepting 'a pointer to %1': ;For a %0* ptr0, %1* ptr1

Hi all, I'm trying to get llvm to optimize away the %cmp to true in define i32 @foo(i32* %array, i32* %length_ptr, i32 %init) { entry: %length = load i32* %length_ptr, !range !0 %len.sub.1 = sub i32 %length, 1 %upper = icmp slt i32 %init, %len.sub.1 br i1 %upper, label %loop, label %exit loop: %civ = phi i32 [ %init, %entry ], [ %civ.inc, %latch ] %civ.inc = add i32 %civ, 1

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

There's another issue with re-running the vectorizer (which I support, btw - I'm just saying there are more problems to solve on the way :-) ) Historically, we haven't even tried to evaluate the cost of the "constant" (not per-iteration) vectorization overhead - things like alias checks. Instead, we have hard bounds - we won't perform alias checks that are "too

1. ————— Dan, The reasoning given below for how GVN operates seems odd to me, Poison is an attribute of a value, just like nsw is an attribute of an operation, So when GVN sees a pair of equal values, one of which has an extra attribute, The proper choice for representative value is the one without the attribute, Just like when GVN sees a pair of add operations, one of which has an