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

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 23 13:49:07 PST 2017


On Mon, Jan 23, 2017 at 10:28 AM, Davide Italiano <davide at freebsd.org> wrote:
> 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.

Yeah, I'm a little concerned about using the release branch for this.

We release fairly often, so these changes will be available to users
of the release in six months, and if they want more bleeding edge than
that, I think building from trunk is the way to go.

Thanks,
Hans


More information about the llvm-commits mailing list