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. > Perhaps it doesn't need to compute all the modes. The existing > TARGET_MODE_NEEDEDÂ can be re-used as an early check to tell whether an insn > has a particular mode setting requirement. 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. > 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. -- Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ Free Software Activist FSFLA co-founder GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity. Excluding neuro-others for not behaving ""normal"" is *not* inclusive!
