similar to: [RFC] NewGVN

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

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 6 Jan 2018, at 04:53, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Jan 5, 2018 at 8:39 PM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Greetings, > > I just found a bug in NewGVN: https://bugs.llvm.org/show_bug.cgi?id=35839

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

Yes, the bug tracks it, and there are one or two major issues. I have patches half done for them, and am more than happy to give guidance/help in getting them done (and i've done this successfully with 3 interns so far :P) On Tue, Jan 9, 2018 at 9:31 AM, Florian Hahn <florian.hahn at arm.com> wrote: > Hi Amara, > > On 08/01/2018 19:26, Amara Emerson via llvm-dev wrote: >

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"

On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > >On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: > >>>> Thank you all for your replies. > >>>> So here seems to be an agreement that the documentation for > >>>> PartialAlias is incorrect. > >>>>

Hi Amara, On 08/01/2018 19:26, Amara Emerson via llvm-dev wrote: > > Is there an umbrella PR or something that could help organise what > someone would have to do/take on in order for it to be enabled? > Outstanding design issues or critical blocking bugs etc. > > Amara > It seems like [META][GVN] NewGVN Integration [1] tries to keep track of bugs/tasks for NewGVN.

On Sat, Jul 15, 2017 at 5:35 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>> >>>> Thank you all for your replies. >>>> So here seems to be an agreement that the documentation for >>>> PartialAlias is incorrect. >>>>

> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >> Thank you all for your replies. >> So here seems to be an agreement that the documentation for PartialAlias >> is incorrect. >> >> Daniel: now you got me wondering about MustAlias. This is what the docs >> say: >> "The MustAlias response may only be returned if the two memory objects >> are

On 16 Nov 2016, at 19:03, Davide Italiano <davide at FreeBSD.org> wrote: > >>> >>> For our target, this is only sound if you can show that the pointer was >>> used to read all of the bytes that you are loading (we have byte-granularity >>> memory safety). Old GVN has no hooks for targets to specify whether this is >>> safe and so is

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’

On Sun, Jul 16, 2017 at 2:34 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes wrote: >>> >>>> On 07/15/2017 04:51 AM, Nuno Lopes wrote: >>>> >>>>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>>>>> >>>>>>> Thank you all for your replies.

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

Hi everybody. NewGVN was recently committed and a few minute ago I added a flag to enable the new experimental pass. For the brave soul, passing `-mllvm -enable-newgvn` should do the trick. We'll be happy to receive bug reports to analyze/fix, bonus point if they contain a synthetic/reduced testcase. Open a bug linked to https://llvm.org/bugs/show_bug.cgi?id=30995 would be probably best so

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 16 Nov 2016, at 21:56, Daniel Berlin <dberlin at dberlin.org> wrote: > > You keep talking about platforms, but llvm ir itself is not platform dependent. > Can you give a reference in the language reference that says that this is not legal? Nothing in the LangRef (apart from the note about non-integral pointers, which was added recently) makes any claim about the representation

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