[llvm] r292648 - NewGVN: Fix PR 31686 and PR 31698 by rewriting store leader handling.

[Davide Italiano via llvm-commits]

On Mon, Jan 23, 2017 at 10:23 AM, Hans Wennborg <hans at chromium.org> wrote:
> On Fri, Jan 20, 2017 at 1:33 PM, Davide Italiano <davide at freebsd.org> wrote:
>> On Fri, Jan 20, 2017 at 1:04 PM, Daniel Berlin via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>>> Author: dannyb
>>> Date: Fri Jan 20 15:04:30 2017
>>> New Revision: 292648
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=292648&view=rev
>>> Log:
>>> NewGVN: Fix PR 31686 and PR 31698 by rewriting store leader handling.
>>>
>>
>> Can we backport this to 4.0 ?
>
> There's a merge conflict. Maybe it's just formatting, but it makes it
> more work to backport.
>
> In general I'm starting to feel more skeptical about merging these
> since NewGVN isn't on by default.
>
> Trunk seems to be changing a bunch here, so there's work in keeping
> up, and there's risk in taking the merges since even if the pass is
> not enabled it does need to build and pass tests.
>
> Why shuold we merge this one?
>

After all these fixes NewGVN is more stable and in a state where it
can be tested by people. Many downstream consumers don't track trunk,
just upgrade every stable release, so asking them to pass `-mllvm
-enable-newgvn` to clang is much easier than asking them to get the
latest version of LLVM, build and try (in particular considering we
don't have nightly builds ;)). I have a similar problem internally, as
we branch on each major release, but  I can workaround it backporting
the patches in our private tree, FWIW.

Anyway, if you don't feel confident backporting these changes, I won't insist.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare