https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
--- Comment #7 from Hongtao.liu <crazylht at gmail dot com> --- (In reply to rsand...@gcc.gnu.org from comment #6) > Please don't do the peephole thing! This seems like a > target-independent problem. > > The costs for r117 look odd. Why is the cost of GENERAL_REGS so high > when the use (before the introduction of insn 13) explicitly requires > GENERAL_REGS? > > Given those costs, the behaviour after the patch looks correct > (on the basis of the information its working with, I mean, > even though it's not the desired effect). (define_insn "vsx_mov<mode>_64bit" [(set (match_operand:VSX_M 0 "nonimmediate_operand" "=ZwO, wa, wa, r, we, ?wQ, ?&r, ??r, ??Y, <??r>, wa, v, wa, wa, ?wa, v, <??r>, wZ, v") (match_operand:VSX_M 1 "input_operand" "wa, ZwO, wa, we, r, r, wQ, Y, r, r, wE, jwM, eQ, eP, ?jwM, W, <nW>, v, wZ"))] "TARGET_POWERPC64 && VECTOR_MEM_VSX_P (<MODE>mode) && (register_operand (operands[0], <MODE>mode) || register_operand (operands[1], <MODE>mode))" { return rs6000_output_move_128bit (operands); } Because the backend pattern explicitly disparage the alternative (<??r>, r), (??r, Y) which moves from GENERAL_REGS/MEM to GENERAL_REGS. And in cost calculation, RA will add extra 2 for each '?', that's why cost of GENERAL_REGS is so high. If manually remove ?? from ??r, then the cost for GENERAL_REGS will become 0, then RA can allocate r117 as GENERAL_REGS, the extra move can be eliminated by pass_reload. ----------cost after removing ?? from ??r-------------- a2(r117,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0 ALTIVEC_REGS:0,0 VSX_REGS:0,0 GEN_OR_FLOAT_REGS:12000,12000 GEN_OR_VSX_REGS:12000,12000 MEM:0,0 -----------end----------------------- So it looks like an target dependent issue, the backend dislike allocating GENERAL_REGS for V2DFmode move, but inline asm explicitly want it to be in GENERAL_REGS.