https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #12 from Jeffrey A. Law <law at redhat dot com> --- I think the cascading problem can be pretty easily addressed. The problematical sequence of insns would look something like this: A (set (r0) (expression)) B (set (r1) (extend (r0)) C (set (r0) (extend (r0)) If we process B first, then we will set the modified flag for A as well as a mode for A. At that time we will verify that (set (r0) (r1)) in the desired mode is valid. We'll update A appropriately and queue B for removal and a copy insn for insertion. If we then process C, we may decide that we want an even wider mode for A. This will change A in the obvious ways. At a later point we'll emit the queued copy insn which take the wider mode which has not been verified and we lose. The key realization is that we can store more than just "we modified A". So when processing B, we set A's state to "modifed, do not change its mode further". When we process C, we'd see that status on A and punt optimizing C. I would expect this to be rare in practice, but I'll do some experiments to see how often we have to suppress an optimization.
