This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow managing
arbitrary PHI-ing of EFLAGS with general PHI insertion. Neither of these
seem at all promising so if those cases come up, we'll almost certainly
need to rewrite the parts of LLVM that produce those patterns.
We do now require dominator trees in order to reliably diagnose patterns
that would require PHI nodes. This is a bit unfortunate but it seems
better than the completely mysterious crash we would get otherwise.
This infinite loop with selects of undef feels over-reduced. It seems fragile, since a pass could come along and optimize the select to the non-undef operand.
I liked the test case from PR37133, but it's reliance on debug info (any, not just standalone) scares me:
We should reopen it or file a split separate bug, because we generate two more BBs on that code when debug info is enabled. :(
In any case, is there a better way to write this test case using legalized arithmetic? An i128 x64 test case with live-out eflags might also be interesting.