On 3/3/2026 8:11 PM, Oleg Endo wrote:
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 implies the dataflow isn't really expressed properly at this point
in the compiler. We can think of it a lot like cc0 or the vector
configuration for risc-v vectors.
For the the former we either fully expose cc0 prior to register
allocation (and deal with the potential that reload/LRA will introduce
insns that clobber cc0, which is painful). The other approach for cc0
is to hide it until after register allocation and reloading and add cc0
to the RTL during a post-reload splitting pass. That's painful too,
just in different ways.
For risc-v vector configuration we're in a similar boat. Something like
vector->vector move potentially triggers vsetvl needs and thus changes
to the vector configuration. And if we were to try and handle that,
then we'd need to be able to allocate scratch registers to hold the
vector configuration around spills. Instead we defer insertion of the
vector configuration management until after reload (using an LCM style
algorithm much like mode switching).
I'd tend to think we'd likely be better off deferring the mode switching
for FP state on SH until after reload. So essentially prior to that
point we let the generic parts of the compiler run wild, then we run an
insertion pass to insert the proper mode switching after reload.
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"?
It's a piece of that problem. You certainly need to describe the
dataflow. You also need to do the mode switching insertions which rely
on correct dataflow of the mode register to know where to insert the
mode switches.
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.
Yea. It's fugly in many respects. I guess at a high level what I'm
suggesting is to get those use/clobbers everywhere you need then, then
run the mode switching pass after reload/lra. There's really not a
great way to do what you need to do if reload can insert insns that
clobber the mode or require new mode switches.
Jeff
