problem in Hitachi SH mulsi3?

[Toshiyasu Morita <tm at netcom dot com>]

I've noticed that the Hitachi SH mulsi3 definition uses a hard reg:

(define_expand "mulsi3"
  [(set (reg:SI 21)
        (mult:SI  (match_operand:SI 1 "arith_reg_operand" "")
                  (match_operand:SI 2 "arith_reg_operand" "")))
   (set (match_operand:SI 0 "arith_reg_operand" "")
        (reg:SI 21))]
  ""
  "
{
  rtx first, last;

  if (!TARGET_SH2)
...
  else
    {
      rtx macl = gen_rtx_REG (SImode, MACL_REG);   <----- here

      first = emit_insn (gen_mul_l (operands[1], operands[2]));
      /* consec_sets_giv can only recognize the first insn that sets a
         giv as the giv insn.  So we must tag this also with a REG_EQUAL
         note.  */
      last = emit_insn (gen_movsi_i ((operands[0]), macl));
    }
  /* Wrap the sequence in REG_LIBCALL / REG_RETVAL notes so that loop
     invariant code motion can move it.  */
  REG_NOTES (first) = gen_rtx_INSN_LIST (REG_LIBCALL, last, REG_NOTES 
(first));
  REG_NOTES (last) = gen_rtx_INSN_LIST (REG_RETVAL, first, REG_NOTES (last));
  DONE;
}")

While I was searching for other examples of REG_LIBCALL/REG_RETVAL usage,
I found this comment in mn10200.md for the addsi3 expander:

;; We want to avoid using explicit registers; reload won't tell us
;; if it has to spill them and may generate incorrect code in such
;; cases.

Does this comment apply to the Hitachi SH mulsi3 expander pattern as well?
I currently have a sample where reload fails to generate a spill/restore 
for a macl used by the mulsi3 pattern (Cygnus case 102938) and if this
comment is relevant, then it would explain why this problem occurs.

Toshi