On Tue, Aug 11, 2020 at 07:59:44AM +0100, Richard Sandiford wrote: > >> I agree there's no obvious reason why splitting to a single insn > >> should be rejected but a peephole2 to a single instruction should be OK. > >> And reusing the existing, tried-and-tested code is the way to go. > > > > The only obvious difference is that the splitters run many times, while > > peep2 runs only once, very late. If you make this only do stuff for > > reload_completed splitters, that difference is gone as well. > > Yeah, but I was talking specifically about RTX_FRAME_RELATED_P stuff, > rather than in general, and RTX_FRAME_RELATED_P insns shouldn't exist > until prologue/epilogue generation.
Yeah, good points. > The reference to “single insn” > was because both passes would still reject splitting/peepholing an > RTX_FRAME_RELATED_P insn to multiple insns. Is that the only thing RTX_FRAME_RELATED_P is actually useful for now, btw? (I do get that it is handy to have the simple cases in the prologue automatically figured out, but that is at best a nicety). What is actually bad about splitting FRAME_RELATED insns, anyway? I can think of many things that could go wrong, but all of those can go wrong with 1-1 splits as well. Maybe this all just works because not very many 1-1 splits are used in practice? So many questions, feel free to ignore all :-) Segher
