On Tue, 2026-03-03 at 08:07 -0700, Jeffrey Law wrote:
>
> >
> > As Kaz mentions in the PR, the relevant SH insn "movsf_ie_ra" has
> > alternatives that have fp-mode requirements and alternatives that don't,
> > i.e. that insn alternative is valid only when cpu/fpu is in the specified
> > mode. The problem is that LRA changes the alternative in the insn without
> > checking whether it would violate the cpu/fpu-mode setting for the insn.
> >
> So there's state outside the predicate (and in fact outside the insn) that
> determines validity? That seems like a problem.
No, there is no explicit state kept outside the insns.
And there is also nothing explicit that would determine validity.
At the moment, the only way to validate an insn/alternative change w.r.t.
cpu-mode switching is:
- find the last effective cpu-mode-changing insn
- extract the mode state from that insn
- look at the insn to be validated alternatives/attributes/whatever to
determine its cpu-mode requirement
- check if required cpu-mode can be fulfilled by last mode that has been set
This could be done. But I don't see it being done anywhere.
> This should be handled by dependence analysis. If it isn't then that's
> also a sign of a target issue. We have similar issues with "vsetvl"
> insertion on RISC-V. Essentially vsetvl sets the vector configuration and
> we insert them fairly late in the pipeline. But if you fully expose the
> dependencies, the it should just work.
>
In order to support C's fenv.h stuff, I have added things like
(clobber (reg:SI FPSCR_STAT_REG))
(use (reg:SI FPSCR_MODES_REG))
for FPU related insns that set and use the FPSCR mode bits already a while
ago. However, this is on a per-insn basis, not per-alternative.
Is that what you mean by "expose the dependencies" and "dependence
analysis"?
I've tried to look in the riscv backend code, but it's a bit too much to
cram into my head for the limited time I have for this, tbh.
The way I understand riscv's "vxrm_mode" attribute is, it computes the
required rounding mode for the insn and that's basically it. I don't see
how this does anything with insn alternatives, dependencies or where or how
those choices might be validated. Again, I have no idea of how the risv
backend is structured, so any pointer or reference is appreciated.
> Now the SH port obviously
> pre-dates LRA and so many other things. I wouldn't be at all surprised if
> 30 years ago it simply wasn't possible to properly model the mode
> switching constraints on insns by having them use a hard register
> representing the FP mode -- especially for movsf/movdf. There were
> numerous restrictions about how those basic move patterns had to be coded
> up that it may not have been possible to expose the dataflow for the FP
> mode properly. But these days it ought to be possible.
Yes, using df analysis we can find out the current cpu/fpu mode and check
whether an insn/alternative would be still valid. But the point I'm trying
to make is, these validations are not done anywhere at this moment.
I don't insist on having cpu/fpu-mode switching work on an alternative
basis. Perhaps we could also change the definition of this framework and
declare that:
- cpu/fpu-mode switching works only on an per-insn basis
- all alternatives of an insn must be valid for a given cpu/fpu-mode
It would require rewriting most parts of the fp-move code in SH, but it
probably would fix the current issue at hand (LRA changing insn alternative
without validating it).
On the other hand, I'm not sure what will happen when LRA's choices of move
insn alternatives are restricted too much. I can imagine at some point it
would try substituting the whole insn. And then we're basically back to
sqrt(1), unless there's already something in LRA that somehow gives the
backend a chance to chime in and validate the current insn/alternative
choice against the current cpu/fpu-mode selection.
I suspect that the riscv vrm and frm modes have no impact on _move_ insn
selection/changes by LRA. That's why it appears to be "just working". On
SH we have the issue that cpu/fpu-mode selection has an impact on move insn
viability and choices. And LRA is basically all about dealing with move
insns, that's where it's hitting the fan.
> >
> > Please let me know what you find out and your thoughts on this.
> >
> Will do. It's in my gcc-17 queue :-)
>
Thanks a lot!
Best regards,
Oleg Endo
