This is an attempt to handle the problem discussed in https://reviews.llvm.org/D68267.
I haven't touched this is sometime. The thing I would worry about is whether *all* of the edges into the successor have been rewritten such that EFLAGS no longer needs to live-in. I don't recall whether the code ensures that is the case in a clear point, but if it does, that is the place to update the live-in list. (I suspect it does somewhere, and it is just finding it in order to do the update correctly... my guess is that it'll be at the end because we're operating edge-wise and may not have finished rewriting edges into the successor... but that's just a guess.)
As far as I can understand, X86FlagsCopyLoweringPass handles one COPY to X86::EFLAGS at a time by finding all its users. The users are found in the current MBB and all the successors (recursively) that has EFLAGS live-in. Each MBB is only visited once and the users are rewritten on the fly, except the jump instructions which are done after all else.
I don't see any part at all updating live-in lists, and I can't find any place in particular that checks that all predecessors of an MBB has been visited. Given that the jumps are done at the end, it would have to be after that, but there is nothing there...
I am not quite sure how this all works, but it seems that EFLAGS is copied into a virtual register (or several - saved in CondRegs) which the users are supposed to rely on, which would then mean that EFLAGS is in fact never live into any MBB with a user found here anymore after this pass?
I made this patch based on this idea which "seems to work", but I am not at all sure this is correct, so please take a look...
The other idea I had was to simply recompute the live-in lists from scratch after everything else, possibly as a new method of LivePhysRegs.