Intergraph CLIPPER bug...

["Mackinlay, Patrick" <patrick dot mackinlay at kjv dot com dot au>]

I'm hoping some kind soul with more understanding of gcc's .md file
semantics and syntax can help me resolve a bug for the
clipper-intergraph-clix target. I've tracked down this problem to the "block
move" section of clipper.md, and have  included the relevant portion below:

[---]
;;
;; block move
;;
(define_expand "movstrsi"
  [(parallel
    [(set (match_operand:BLK 0 "memory_operand" "")
          (match_operand:BLK 1 "memory_operand" ""))
     (use (match_operand:SI 2 "general_operand" ""))
     (use (match_operand:SI 3 "const_int_operand" ""))
     (clobber (match_scratch:SI 4 ""))
     (clobber (match_scratch:SI 5 ""))
     (clobber (match_dup 6))
     (clobber (match_dup 7))])]
  ""
  "
{
  rtx addr0, addr1;

  addr0 = copy_to_mode_reg (Pmode, XEXP (operands[0], 0));
  addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));

  operands[6] = addr0;
  operands[7] = addr1;

  operands[0] = change_address (operands[0], VOIDmode, addr0);
  operands[1] = change_address (operands[1], VOIDmode, addr1);

  if (GET_CODE (operands[2]) != CONST_INT)
    operands[2] = force_reg (SImode, operands[2]);
}")

;;
;; there is a problem with this insn in gcc-2.2.3
;; (clobber (match_dup 2)) does not prevent use of this operand later
;; we always use a scratch register and leave operand 2 unchanged
;;
(define_insn ""
  [(set (mem:BLK (match_operand:SI 0 "register_operand" "r"))
	(mem:BLK (match_operand:SI 1 "register_operand" "r")))
   (use (match_operand:SI 2 "nonmemory_operand" "rn"))
   (use (match_operand:SI 3 "const_int_operand" "n"))
   (clobber (match_scratch:SI 4 "=r"))
   (clobber (match_scratch:SI 5 "=r"))
   (clobber (match_dup 0))
   (clobber (match_dup 1))]
  ""
  "*
{
  extern void clipper_movstr ();
  clipper_movstr (operands);
  return \"\";
}"
[(set_attr "cc" "clobber")])
[---]

The body of the loop generated by an "optimised" memcpy() call looks
something like this:

.L1:
	loadw (r1),r1
	addq  $4,r1
      storw r1,(r2)
	addq  $4,r2
      subq  $4,r3
      brge  .L1

Obviously, r1 cannot be used both as the source address pointer and the
register holding the data value. The comment about "gcc-2.2.3" above makes
me very suspicious (knowing that the CLIPPER port probably hasn't been
actively exercised since that verison of GCC, and may have a workaround for
a now non-existent problem), and I hope whatever the problem it refers to
has been fixed, and the insn can be redefined in the "correct" way.

Can someone explain to me more about how these constructs in the .md file
work, and possibly point out how/why the compiler is not allocating a new
register for the data value? The clipper_movstr() function looks correct to
me, but it's (obviously) in clipper.c if it's important. I don't understand
the relationship between the define_insn and the define_expand, either.

I'm using gcc-2.95.3 for the moment, and once I have it building valid
CLIPPER code, I'll start afresh with a current gcc snapshot (probably 3.0.2
by the time I get there).

Thanks in advance to anybody patient enough to help a gcc newbie out...

Regards,
Pat Mackinlay
Kellogg Joint Venture