> Backporting this is okay. (It was not done because it does not affect > correctness). What is the "almost", btw?
The predicate of operand #0 of movdi_internal32 is rs6000_nonimmediate_operand on the 7 branch and nonimmediate_operand on the 8 branch and later. > (In https://gcc.gnu.org/ml/gcc-patches/2016-11/txt4j9hLRLCzf.txt and you > presumably mean the *movdi_internal32 hunk, and the first line of it: > > - "=Y, r, r, ?m, ?*d, ?*d, > + "=Y, r, r, ^m, ^d, ^d, > > where the last three are mem<-reg, reg<-mem, reg<-reg, for fp regs). > > This patch was a year before we switched to LRA, and for non-LRA ports * > does not do any register preferencing. Are you sure? See record_reg_classes in ira-costs.c: case '*': /* Ignore the next letter for this pass. */ c = *++p; break; > For 6xx/7xx people *wanted* to use FP loads and stores whenever possible, > because you get twice the bandwidth with them. > > If you do not want the FP registers used (or FP insns used), use > -msoft-float, that's what it's for. No disagreement, but you can't force people to use it when they use FP code in other parts of their software. Believe me, we (and probably others) tried... > Patches are welcome, but complicating this already very complex code by > introducing an arbitrary distinction between "embedded and other" (or > actually, "server and other") isn't the way to go. Sorry. Not clear what you mean by complicating here... the approach is rather simple and precisely aimed at not disturbing the common path, i.e. server processors, while preserving the historical path for other processors. AFAIK nobody has evaluated the effects of the original change beyond POWER 7/8/9. > Could you open a PR please? Sure, but about what now? ;-) -- Eric Botcazou
