similar to: [RFC] NewGVN

On Wed, Nov 16, 2016 at 2:03 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This is really great to see, as I’ve spent far too much of my life over > the past two years fighting with undocumented assumptions made by GVN. A > couple of quick questions about the new GVN, based on problems I’ve had > with the old one: > > Does it assume that it’s

So i have a testcase (see PR31792, and cond_br2.llin GVN) that current GVN can simplify because it replaces instructions as it goes. It's an example of a larger issue that pops up quite a lot I would appreciate thoughts on what to do about it it amounts to something like this (but again, it happens a lot): live = gep thing, 0 live2 = gep thing, 1 branch i1 provablytrue,, mergeblock, otherbb

On Fri, Mar 3, 2017 at 12:39 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: On 3/3/2017 11:51 AM, Daniel Berlin via llvm-dev wrote: So i have a testcase (see PR31792, and cond_br2.llin GVN) that current GVN can simplify because it replaces instructions as it goes. It's an example of a larger issue that pops up quite a lot I would appreciate thoughts on what to do about it it

On 02/27/2017 01:47 PM, Daniel Berlin wrote: > > > On Mon, Feb 27, 2017 at 11:29 AM, Adam Nemet <anemet at apple.com > <mailto:anemet at apple.com>> wrote: > > >> On Feb 27, 2017, at 10:11 AM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 02/27/2017 11:47 AM, Adam Nemet wrote:

I have tried running both gvn and newgvn but it did not helped in hoisting the alias checks: Please check, maybe I have missed something. <TestCase> void foo (char *A, char *B, char *C, int len) { int i = 0; for (i=0 ; i< len; i++) A[i] = B[i] + C[i]; } <Command> $ opt –O3 –gvn test.ll –o test.opt.ll $ opt –O3 –newgvn test.ll –o test.opt.ll “test.ll” is attached, it

Hi Daniel, Got it. If that's the case, can I implement it under the guidance of your insights/prototype? I think I can spend more time on implementation. Thanks, Taewook ________________________________ From: Daniel Berlin <dberlin at dberlin.org> Sent: Tuesday, April 4, 2017 9:41:30 PM To: Taewook Oh Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [NewGVN] Plan for GVNPRE? Of

> On Feb 27, 2017, at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Mon, Feb 27, 2017 at 9:29 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: > >> On Feb 27, 2017, at 7:27 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 02/27/2017 06:29 AM,

Hello, In some of our internal benchmarks, I observe that LLVM performs worse than GCC because LLVM fails to perform PRE when GCC can. I hope this problem goes away when NewGVN equipped with PRE, and wonder if anyone has an idea about the status of PRE on top of NewGVN. Thanks! Best, Taewook -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

> On Feb 27, 2017, at 10:11 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 02/27/2017 11:47 AM, Adam Nemet wrote: >> >>> On Feb 27, 2017, at 9:39 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: >>> >>> >>> >>> On Mon, Feb 27, 2017 at 9:29 AM, Adam Nemet <anemet at

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

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 <

Daniel, Thanks for taking the time to respond. Regarding GVN and newGVN, I recently finished a search through the llvm-dev archives for “nsw” in the subject line, and GVN was discussed in some of those threads [1]. In particular it was claimed that there was a right choice for GVN to make given two ADD instructions, one with the “nsw” attribute and one without, the one without ‘nsw’

Hi Daniel, Thank you for your detailed reply, and thank you for working on GVNPRE. I’d more than happy to test/evaluate it with our benchmark once it is ready. Please let me know if you need any help. Thanks, Taewook From: Daniel Berlin <dberlin at dberlin.org> Date: Tuesday, April 4, 2017 at 6:13 PM To: Taewook Oh <twoh at fb.com> Cc: "llvm-dev at lists.llvm.org"

Summarizing the discussion on the implementation approaches. Discussed about two approaches, first running ‘InnerLoopVectorizer’ again on the epilog loop immediately after vectorizing the original loop within the same vectorization pass, the second approach where re-running vectorization pass and limiting vectorization factor of epilog loop by metadata. <Approach-2> Challenges with

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 Fri, Nov 18, 2016 at 8:43 AM, Philip Reames via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> Glad to see this landing! It's been a long time coming. >> >> Once this is in, please do not turn it on by default immediately. Let's >> call for volunteers to find some of the most egregious miscompiles, fix >> them, and then turn this on by

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>

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

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