On Wed, 2026-03-11 at 04:27 -0300, Alexandre Oliva wrote:
> On Mar 10, 2026, Oleg Endo <[email protected]> wrote:
>
> > When LRA (or any other pass for that matter) tries to change an
> > insn/alternative it won't automatically introduce new insns that do an
> > "fp_set", because those are emitted only by mode-switching.cc once at those
> > points where it deems necessary.
>
> Yup. That's why my suggestion was to only accept modifications that
> don't change these attributes, so that no mode-changing instructions
> would be needed.
Ah, I think now I know what you mean!
Only look at the mode-switching requirements attributes. If the change of
insn/alt requirement would cause an uncertain state (because we're not
really tracking the mode state now), reject it entirely.
So we get:
insn/alt with "fp-any" attr: can change to "fp-any" only
(because state not known for certain)
insn/alt with "fp-single" attr: can change to "fp-single" or "fp-any"
insn/alt with "fp-double attr: can change to "fp-double" or "fp-any"
Yeah, that looks like a possible hot-fix for SH.
However, I don't know how well this will scale. For example, I'd like to
add more fp-mode switches in the future, which would affect fp move insns
quite a bit.
> Something like that could work on SH, but only because we don't use the
> HARD_REG_SET that mode_needed takes as parameter, and because most insns
> don't have specific mode requirements. Other ports such as aarch64 IIRC
> use the HARD_REG_SET, so we'd need to compute it like mode-setting.cc,
> and it's not a given that any of the target modes will have a most
> frequent don't-care setting we could use to avoid the detailed
> validation.
I have briefly looked at how aarch64 is using the HARD_REG_SET, but don't
know enough about it to fully understand this use case.
>
> > Theoretically, all passes following the initial mode-switching.cc would need
> > to do this validation for each insn change ...
>
> Yup. It's something that validate_change should check. But given the
> need for the HARD_REG_SET on some ports, we may need to introduce and
> use a new mode-setting hook that doesn't, and that can figure out modes
> before and after applying the (group?) changes without resorting to the
> reg set in target-specific ways; hopefully that's possible. If it
> isn't, perhaps a different API will be needed. Surely we don't want to
> recompute the live regs at every insn change.
>
Yes, a mode-switching API extension is inevitable to fix this issue, IMO.
It would require a function to compute the current mode value (current
cpu/fp mode state) set and another function to compute the required mode
value of (the new, changed) insn/alt.
Automatic computation of current mode states via default implementation
using df-analysis sounds nice. But it would require an API for the target
to define what is a mode register and what's the meaning of its contents and
so on.
If the validation itself should also be transparent and automagic then it'd
need a way to compare mode register contents and judge the compatibility of
modes. The current "int entity" API of mode-switching.cc might be a bit too
simplistic for that.
Handling of insn group changes is a good point, but I think it boils down to
checking each insn in the group for mode state compatibility.
Another interesting use case could be if the backend injects/emits mode
switches by itself, after the initial mode-switching.cc pass, e.g. via
(define_split or (define_insn_and_split patterns in the .md.
Best regards,
Oleg Endo
