On 3/2/2026 10:11 PM, Oleg Endo wrote:
Firstly, I forgot to mention the original PR in the subject line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
Ah, I hadn't seen that.
I wanted to look at it deeper before commenting, but my first impression
was this patch is a bad idea.
I can relate to your concern. In my first message I wrote:
"Eventually LRA should be taught to check that any substitution is
valid....". Below the expanded version of it.
Yea. It's a sore spot, though reload has had this quirk as long as I
can remember as well. I'd love to see it fixed, but given we've been
carrying around this behavior for decades, it may be "nontrivial" to fix.
It sounds like it's papering over a
target issue, but again, I really want to look at it more deeply.
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.
The next problem, according to my understanding, is that there is actually
nothing there that is storing/tracking the current cpu/fpu-mode across
insns. It seems it's not even directly possible to determine the cpu/fpu-
mode state for a given insn directly outside of mode-switching.cc. We can
try to _guess_ it by looking at which alternative is currently selected, but
it still can't give a definitive answer.
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.
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.
The whole SH move insn stuff turned into an unmaintainable gibberish, imo.
Lockstepping through the insn alternatives and trying to guess what it's
supposed to accomplish is just too tedious and error prone. Adding the LRA
thing on top makes it even worse, as it runs into issues like this one.
Perhaps it'd be better to split the patterns into smaller bites and also
chop off some old cruft that is no longer needed/valid. However, I'd do
that only after switching to LRA.
I suspect at least some stems from the old reload requirement that you
had to have a single insn for movsi, another for movdi and so-on. Many
ports weren't good about this, but the failure modes were pretty
obscure, so they got away with it.
In the LRA world I think we do have the option to simplify this stuff
somewhat.
Please let me know what you find out and your thoughts on this.
Will do. It's in my gcc-17 queue :-)
Jeff
