https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #35 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Martin Liška from comment #15) > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9. This change goes against what HONOR_REG_ALLOC_ORDER is documented on doing (I Mean the false case of HONOR_REG_ALLOC_ORDER): Normally, IRA tries to estimate the costs for saving a register in the prologue and restoring it in the epilogue. This discourages it from using call-saved registers. If a machine wants to ensure that IRA allocates registers in the order given by REG_ALLOC_ORDER even if some call-saved registers appear earlier than call-used ones, then define this macro as a C expression to nonzero. Default is 0. Since r8 is still a caller-saved register, HONOR_REG_ALLOC_ORDER should not make a difference here. The order for rs6000 is: MAYBE_R2_AVAILABLE \ 9, 10, 8, 7, 6, 5, 4, \ 3, EARLY_R12 11, 0, \ Still that should apply here rather than register number based. Really doing cost based on register # seems incorrect anyways. These are all caller-saved registers IIRC. r0 is special in rs6000 where it sometimes cannot show up; e.g. base+reg base cannot be r0.
