On Thu, 2026-07-02 at 09:34 +0200, Richard Biener wrote: > > Is splitting the instruction patterns a viable way to prevent LRA from > using one over the other? Possibly patterns could be made non-recognizable > (but we don't re-recog during LRA, just select alternatives?) by making > mode-switching add an explicit "mode" operand.
Maybe it could be another way to model the whole thing. The way it's done now is via insn attributes which also work at alternative granularity. There is already some information there which mode the insn/alt is currently requesting. It's just that nothing is attempting at checking it. > I don't know how many patterns would be affected, of course, or how many > modes exist. SH4 FPU has two modes: - select single/double precision mode (fpscr.pr) - select single/double fp move mode (fpscr.sz) Currently it's utilizing only fpscr.pr. To toggle fprscr.sz we have an insn "fschg", but it's only valid when fpscr.pr = 0 (yey!). To toggle fpscr.pr we need to use some arithmetic and general regs to manipulate the fpscr setting (yey 2.0!). Let's say LRA needs to insert a dobule-fp-move at a certain point in the insn stream. There are two cases: - either fpscr.sz = 0 -> insert 2x single-fp move - or fpscr.sz = 1 -> insert 1x double-fp move One way or another, it will require some infrastructure to figure out what the current mode is in order to make the appropriate choice. Currently there is no way to explicitly query the mode state at a particular point in the insn stream. And that was one of the points where we stopped at. I have some ideas how to improve this whole thing and will try to continue working on it in the background. Most importantly, we can complete the SH LRA migration for now. Best regards, Oleg Endo
