Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Mon, Aug 10, 2020 at 05:16:15PM +0100, Richard Sandiford wrote: >> Senthil Kumar via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> > The wiki suggests using post-reload splitters, so that's the >> > direction I took, but I ran into an issue where split_insn >> > bails out early if RTX_FRAME_RELATED_P is true - this means >> > that splits for REG_CC clobbering insns with >> > RTX_FRAME_RELATED_P will never execute, resulting in a >> > could-not-split insn ICE in the final stage. >> > >> > I see that the recog.c:peep2_attempt allows splitting of a >> > RTX_FRAME_RELATED_P insn, provided the result of the split is a >> > single insn. Would it be ok to modify try_split also to >> > allow those kinds of insns (tentative patch attached, code >> > copied over from peep2_attempt, only setting old and new_insn)? Or is >> > there >> > a different approach to fix this? >> >> 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. The reference to “single insn” was because both passes would still reject splitting/peepholing an RTX_FRAME_RELATED_P insn to multiple insns. Thanks, Richard
