So, to me this looks like a backend bug, using dead_or_set_p in a splitter when the split passes don't really compute the note problem. Seems s390 is the only backend that does this, other backends use dead_or_set_p either only in peephole2s (which is fine, peephole2 pass starts with
df_set_flags (DF_LR_RUN_DCE);
df_note_add_problem ();
df_analyze ();
and even when many targets don't use df_or_set_p, they do use peep2_dead*), or (cris) in delayed branch scheduling (I believe that doesn't guarantee that either). Can't what you are doing in the splitters be done in define_peephole2 instead?
So, to me this looks like a backend bug, using dead_or_set_p in a splitter when the split passes don't really compute the note problem. Seems s390 is the only backend that does this, other backends use dead_or_set_p either only in peephole2s (which is fine, peephole2 pass starts with add_problem ();
df_set_flags (DF_LR_RUN_DCE);
df_note_
df_analyze ();
and even when many targets don't use df_or_set_p, they do use peep2_dead*), or (cris) in delayed branch scheduling (I believe that doesn't guarantee that either). Can't what you are doing in the splitters be done in define_peephole2 instead?