On Tue, Dec 16, 2014 at 07:28:22AM -0600, Segher Boessenkool wrote: > and "type0" is when it didn't > do either but still ended up with I1 and I2 the same UID (I think it > might be called with the same insn twice; not a good thing, it does > not know how to handle this; and it is really worrisome that it then > sometimes succeeds in combining it).
... and when I make try_combine immediately refuse duplicates in I0,I1,I2 everything works again. When INSN_UID (i1) == INSN_UID (i2), calling df_insn_delete (i1) does set the "should be deleted" flag on i2 instead, but try_combine later calls df_insn_rescan (i2) which resets it again. This is icky and looks very wrong in the debug dump, but it does work fine. Doing an (effictively) 2->2 combine like this still feels quite unsafe wrt combine possibly looping, but it has worked for over twenty years. Bootstrapping, making new test results, will send a new patch later today. Thanks for pushing me to look much closer, Segher