Additionally, r298887 and r299558 for a problematic ARM/AArch64 test case.

This looks like it will break the ABI. Also, this is a pretty big patch, does it fix a bug?

It seems to be a performance improvement more than a bugfix. Even if there was a bug fixed in the process, I believe this one is just too big and core behavioural changing enough that it might not be a good candidate to a backport.

The two following revert/reapply also get me worried that there is an unstable behaviour that we'll be introducing...

It is not just a performance improvement. It fixes a regression where clang 4.0 can't build the Xen kernel due to some dependencies on DSE. The revert/reapply was for a supposedly flaky test case. The test case was problematic before, so that was nothing new.

Is there some less invasive way to fix the bug?

Is there some less invasive way to fix the bug?

Difficult, since the test infrastructure wants to really have two names for the pass. I'm not sure having an untested branch is an improvement.

Adding folks in the original revision to get more eyes.

I still think this is too big (not just in size, but possibilities of things to go slightly wrong).

With llvm 5.0 coming out in July, I personally don't think we should merge in 4.0.1, but I'll leave it up to the people in the original review to have the final say.

cheers,
--renato

This seems too risky to me. Changes to the optimizations we run early in the pass pipeline can have wide-reaching effects, and we want to minimize the risk of exposing new bugs in a dot release.

Based on feedback, I don't think we are going to be able to merge this patch.