similar to: Call for testing/heads-up: NewGVN

Hi, I’m curious if the test-suite running cleanly with this flag? (That would be a first step before wider testing). Thanks, — Mehdi > On Dec 26, 2016, at 10:45 AM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi everybody. > NewGVN was recently committed and a few minute ago I added a flag to > enable the new experimental pass. > > For the

Also: does clang bootstrap and pass the tests (and builds the test-suite correctly?). — Mehdi > On Dec 26, 2016, at 12:54 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I’m curious if the test-suite running cleanly with this flag? > (That would be a first step before wider testing). > > Thanks, > > — > Mehdi >

I assume that this passes all the lit/lnt test cases on the platform that the developers work on. It causes 31 lnt test case failures on PPC. I've opened a bug with the one that is easiest to reduce. Also, I'm happy to assist by providing any further PPC specific information you require regarding this. Nemanja On Mon, Dec 26, 2016 at 9:55 PM, Mehdi Amini via llvm-dev < llvm-dev at

On Tue, Dec 27, 2016 at 3:22 PM, Nemanja Ivanovic via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I assume that this passes all the lit/lnt test cases on the platform that > the developers work on. > Yes I bootstrap/test it. > It causes 31 lnt test case failures on PPC. I've opened a bug with the one > that is easiest to reduce. > Also, I'm happy to assist

These are all caused by a set of failures to properly mark memory users as changed in some cases, and to initialize the memory operand equivalence table properly. I'm thinking how best to solve it. In the meantime, reverting the store equivalence changes should fix most of it (there is one other bug in updateReachableEdge that won't fix, where it misses marking memoryphi's) On Tue,

(and to be clear, reverting it would just hide the bugs pretty well, they'd fix it) I think i have a good way of fixing this properly, patch coming. On Tue, Dec 27, 2016 at 5:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > These are all caused by a set of failures to properly mark memory users as > changed in some cases, and to initialize the memory operand equivalence

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

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

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

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

Thanks. This is a dupe of PR 34452. On Sun, Sep 17, 2017 at 2:40 PM, Andrew Kelley <superjoe30 at gmail.com> wrote: > > On Sun, Sep 17, 2017 at 4:21 PM, Davide Italiano <davide at freebsd.org> > wrote: > >> Dump the IR before newgvn and run through opt -newgvn. It should crash. >> I'm not familiar with your frontend but you might want to use -mllvm

It's basically ready to commit; the reviewers were fairly happy with it. It needs rebasing on top of NewGVN and any bugs that shakes out fixed, but that's about it. I want to get around to it soon-ish, but I've wanted that for a while! On Wed, 26 Apr 2017 at 16:50, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi James, > > I have an ad-hoc solution in mind to solve

> On Sep 27, 2017, at 3:23 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I think that, given previous discussion on the topic, we might want a split >> like this: >>

Hi, Yes, I can see why that would not work. The sinking algorithm in SimplifyCFG isn't particularly clever. In particular it can't reason about memory ordering and aliasing. In unswitch1(), it can identify that the stores correlate because the correlating stores appear in the same relative source order. In unswitch2() they have been permuted, and the algorithm cannot deal with this. This

Hi. I'm sending this email to -dev as this may be of interest of many/people may have opinions/want to try the change before it goes in to report problems. I've been recently working on a patch to integrate `undef` in the SCCP solver, in the hope of fixing a tail of latent bugs in SCCP which remained uncovered for many years. I think this is a decent time to propose, so that it can

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

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"