From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Mitchell <mark@codesourcery.com>
To: geoffk@cygnus.com
Cc: gcc@gcc.gnu.org
Subject: Re: ssa bootstrap problem on x86 (cmpstrsi_1 pattern)
Date: Wed, 26 Jul 2000 22:55:00 -0000
Message-id: <20000726225456J.mitchell@codesourcery.com>
References: <200007230424.VAA00564@localhost.cygnus.com> <20000723005001R.mitchell@codesourcery.com> <200007241850.LAA01805@localhost.cygnus.com>
X-SW-Source: 2000-07/msg00851.html

I'm sorry I took a couple of days to reply.  I've been staring at you
mail trying to get it go into my brain in a way that makes sense to
me, but I'm afraid I'm still stuck.

  It does.  I'm assuming that reg 35 is a pseudo (since SSA
  doesn't apply to hard registers).  It looks like:

(As I've said before, it soon will.  We've already got code to
selectively but those hard registers into SSA form for which it makes
sense.  In our patches, the MD file says which hard registers should
be SSA-ified.)

  (sequence [
    (set (reg:SI 10035) (reg:SI 35))
    (parallel [
      (SET (reg:CC 17) 
	(if_then_else:CC (ne (reg:SI 10035) (const int 0)) ...)
      (USE (reg:CC 17))
      ...
      (CLOBBER (reg:SI 10035)))
      ...])
   ])

  You can see that, taken as a whole, this insn has an input that is
  not changed, and an outputs which is new to this insn.

But the property that 10035 is valid in all blocks which are dominated
by this block does not hold.  And that is a very valuable property of
SSA form.  You have to know that 10035 is a special register, created
only for this purpose.  I understand how this could be made to work,
but I still don't see an advantage over just doing:

  (parallel [
      (SET (reg:CC 17) 
	(if_then_else:CC (ne (reg:SI 35) (const int 0)) ...))
      (USE (reg:CC 17))
      ...])
   ])

I'd add the CLOBBER (and make the transformation you suggest involving
introducing the extra register) after leaving SSA form, or perhaps
very late in the game in SSA.  In other words, just postpone
introducing the CLOBBER until later.

To me, that makes sense.  Abstractly, string-comparison doesn't alter
the input operands.  On the x86, it does -- but that's a hardware
detail.  Low-level passes, like scheduling, register allocation, and
so forth need to know about that -- but high-level passes like
dead-code elimination, loop unrolling, loop invariant code motion,
etc. probably don't.

  The reason match_scratch helps is that we could just write the same
  pattern as

  (define_insn "cmpstrsi_1"
    [(set (reg:CC 17)
	    (if_then_else:CC (ne (match_operand:SI 2 "register_operand" "c")
				 (const_int 0))
	      (compare:SI (mem:BLK (match_operand:SI 0 "address_operand" "S"))
			  (mem:BLK (match_operand:SI 1 "address_operand" "D")))
	      (const_int 0)))
     (use (match_operand:SI 3 "immediate_operand" "i"))
     (use (reg:CC 17))
     (use (reg:SI 19))
     (clobber (match_dup 0))
     (clobber (match_dup 1))
     (clobber (match_dup 2))]
  ...)

I assume you meant to use `match_scratch' in the last three patterns?
If so, I understand your point; independent of the discussion above,
it would seem that we could make this change in the .md file -- if
Richard thinks it make sense, and reload can handle it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com