[RFC] NewGVN

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

There are no immediate plans to enable NewGVN by default (at least,
not in the near future). In fact, the mail that I originally wrote
doesn't at all mention the switch, neither any follow-ups from me or
Daniel, so, I'm not entirely sure where you got that idea from. If you
take a look more closely (at the mail, or a the patch), you'll realize
that "key" pieces that are in old GVN are still missing. The most
noticeable are PRE and load coercion. In other words, the patch
proposed is not (yet) on par with what the current GVN does (although
all the missing pieces are already implemented out-of-tree).
Also, let me try to clarify one point. This is already a call for
volunteers. If you feel adventurous, you can download the
patch/apply/test/report issues. I can and I will spend time
ntegrating the rest of the work and fix all the reported
bugs/miscompiles. If there's something that can we do in a cleaner
way, a discussion will happen on the mailing list/on the review thread
and everybody will have a chance to comment, as it's happening for the
initial patch (and as I always try to do).
Once the first patch lands, I'll commit a temporary cl::opt to enable
NewGVN for those interested in testing and send another CFT e-mail.
FWIW, The patch had already a round of light testing internally. Of
course, this is not enough or indicative of its maturity/robustness. I
plan to have it tested more carefully inside my organization in
parallel.
That said, thanks for you input.

Why even commit the patch to enable the pass into trunk. Just leave it
up on Phabricator for testers to apply locally to their tree?
             Jack

>> 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 default.
>>
>There are no immediate plans to enable NewGVN by default (at least,
>not in the near future). In fact, the mail that I originally wrote
>doesn't at all mention the switch, neither any follow-ups from me or
>Daniel, so, I'm not entirely sure where you got that idea from. If you
>take a look more closely (at the mail, or a the patch), you'll realize
>that "key" pieces that are in old GVN are still missing. The most
>noticeable are PRE and load coercion. In other words, the patch
>proposed is not (yet) on par with what the current GVN does (although
>all the missing pieces are already implemented out-of-tree).
>Also, let me try to clarify one point. This is already a call for
>volunteers. If you feel adventurous, you can download the
>patch/apply/test/report issues. I can and I will spend time
>ntegrating the rest of the work and fix all the reported
>bugs/miscompiles. If there's something that can we do in a cleaner
>way, a discussion will happen on the mailing list/on the review thread
>and everybody will have a chance to comment, as it's happening for the
>initial patch (and as I always try to do).
>Once the first patch lands, I'll commit a temporary cl::opt to enable
>NewGVN for those interested in testing and send another CFT e-mail.
>FWIW, The patch had already a round of light testing internally. Of
>course, this is not enough or indicative of its maturity/robustness. I
>plan to have it tested more carefully inside my organization in
>parallel.
>That said, thanks for you input.

Why even commit the patch to enable the pass into trunk. Just leave it
up on Phabricator for testers to apply locally to their tree?
             Jack

Because that increase friction to testing it. Asking people to pass -mllvm
-newgvn will end up with a lot more testing than "please apply this patch
and recompile everything".

- Michael Spencer

Right. On trunk I can have it run through swathes of internal test code with a new flag in a matter of mouse clicks through our CI. Having to apply a patch manually is a more involved affair with a lot more manual steps. That’s not to say it can’t be done, but it’s something I’d rather avoid where a far easier solution exists. At that point it becomes a piece of work that I have to schedule and prioritise vs my other responsibilities (and therefore might get done much later or not at all). If it’s just kicking off an automated test run and reporting any bugs that turn up it’s probably something I can just squeeze in straight away without any real planning.

-Greg

Same here. Committed under an off by default flag is far preferred over "apply this patch".

Also, once it's in tree, it's much easier for multiple people to work on it at once. Beyond all the algorithmic stuff, there's all the standard code cleanup and refactoring changes going on in tree. Keeping an out of tree patch up to date w.r.t. API changes can be a real pain.

Philip