Re: ssa bootstrap problem on x86 (cmpstrsi_1 pattern)

[Geoff Keating <geoffk at cygnus dot com>]

> Cc: gcc@gcc.gnu.org
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Wed, 26 Jul 2000 22:54:56 -0700

> 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.)

That's fine.  In fact, I was wondering how we'd deal with hard registers.

>   (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:

???  10035 is indeed valid in all such blocks.  It's not _useful_,
since it holds an indeterminate value, but it has certainly been set,
and it has only been set once.  Hopefully, any kind of dataflow
analysis we do would notice that it was set by a CLOBBER and therefore
does not hold a useful value.

The important point is that register 35 _is_ valid.  It holds the same
value it held before.

> 
>   (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.

You could do it in unssa, but then the problem is that you have to
have special code to recognise this as a valid insn while it is in SSA
form.

> 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.

Oops!  I must have sent the mail before I finished it.  Yes, the idea
would be to use 

(clobber (match_scratch:SI "0"))

or whatever.  

One extra benefit of using match_scratch is that some places will add
extra CLOBBERs if the insn doesn't have them and could be recognised
if it had them.  This may help with the recognition problem I
mentioned above.

-- 
- Geoffrey Keating <geoffk@cygnus.com>