[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

["pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #8 from pinskia at gcc dot gnu dot org  2010-06-21 21:29 -------
(In reply to comment #7) 
> I mostly agree with you. But in this case, it is already a hard register (rtl
> generated in epilogue).

No the pattern accepts any registers which means register rename can rename the
register to what ever registers it feels like.  What register rename
constraints has is to do with stuff that are implicit (like hard registers for
inline-asm and function call arguments).  This case we have an explicit operand
which means we need to mark the constraint to be correct.

For an example:
(define_insn "*restore_gpregs_<mode>"
 [(match_parallel 0 "any_parallel_operand"
                  [(clobber (match_operand:P 1 "register_operand" "=l"))
                   (use (match_operand:P 2 "symbol_ref_operand" "s"))
                   (use (match_operand:P 3 "gpc_reg_operand" "r"))
                   (set (match_operand:P 4 "gpc_reg_operand" "=r")
                        (match_operand:P 5 "memory_operand" "m"))])]
 ""
 "bl %2"
 [(set_attr "type" "branch")
  (set_attr "length" "4")])

Should be changed to:
(define_insn "*restore_gpregs_<mode>"
 [(match_parallel 0 "any_parallel_operand"
                  [(clobber (match_operand:P 1 "register_operand" "=l"))
                   (use (match_operand:P 2 "symbol_ref_operand" "s"))
                   (use (match_operand:P 3 "gpc_reg_operand" "d"))
                   (set (match_operand:P 4 "gpc_reg_operand" "=r")
                        (match_operand:P 5 "memory_operand" "m"))])]
 ""
 "bl %2"
 [(set_attr "type" "branch")
  (set_attr "length" "4")])

(etc.)
Where d is a new constraint.  Though you might need more than one constraint
and patterns because of the following code:
  RTVEC_ELT (p, offset++)
    = gen_rtx_USE (VOIDmode,
                   gen_rtx_REG (Pmode, DEFAULT_ABI != ABI_AIX ? 11
                                       : gpr && !lr ? 12
                                       : 1));

--- CUT ---
I think you might cause other targets to slow down because of the use of
parallels inside jump instructions (mostly indirect calls).


Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618