On Fri, Jul 3, 2026 at 1:56 AM Oleg Endo <[email protected]> wrote: > > 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.
So - make a "modeless" move available to LRA and have a later mdreorg pass "split" that into the appropriate 2x single or 1x double move? That said, possibly do not expose this "move detail" until after LRA and that mdreorg point? That mdreorg of course will have to recover the current insns "mode" somehow. > > 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
