SSA question

[Chris Lattner <sabre at nondot dot org>]

This code (obviously distilled from a larger testcase):

int trys(char *s) {
  int asa, LLS;
  asa = LLS + asa;
  return asa;
}

Is causing this SSA RTL to be emitted (compiled with gcc -da -fssa -O2,
Sparc64 GCC 3.0.4, but happens all the way back to pre 3.0):

(insn 13 28 17 (set (reg/v:SI 107)
        (plus:SI (reg/v:SI 107)
            (reg/v:SI 108))) 177 {*addsi3} (nil)
    (nil))

(insn 17 13 19 (set (reg:DI 110)
        (sign_extend:DI (reg/v:SI 107))) 147 {*sign_extendsidi2_insn} (nil)
    (nil))

(insn 19 17 22 (set (reg/i:DI 24 %i0)
        (reg:DI 110)) 61 {*movdi_insn_sp64_novis} (nil)
    (nil))

I'm wondering why the first set gets generated to refer to its own value
(it seems that PHI nodes should be the only insn's that should do that).
The instruction coming into SSA constructure looks like this [which is
identical to the above insn]:

(insn 13 28 17 (set (reg/v:SI 107)
        (plus:SI (reg/v:SI 107)
            (reg/v:SI 108))) 177 {*addsi3} (nil)
    (nil))

It seems the the renaming code is not assuming that there is an incoming
definition of reg 107, so no renaming has to occur.  Is this desirable
behavior?  Would it be better to mark undefined incoming values as being
used already so that they are renamed and distinct?

Thanks,

-Chris