[df] Always mark the stack pointer as defined on entry.

[Kenneth Zadeck]

> At the moment, df_get_entry_block_def_set only includes the stack pointer
> before prologue and epilogue generation.  I don't see any reason for this.
> It's true that the incoming rtl stack pointer does have a different meaning
> after prologue generation, but its value is still important.
> 
Richard, 

The current code assumes that the prologue generation code will
contain some sort of set of the stack pointer.  The df code is
conditional on that timing so that some sort of set appears to be
there before the prologue is generated.  (In a real compiler, we would
generate the prologue early and we would not be doing any of this
foolishness.)  But after the generation of the prologue, the prologue
is supposed to have everything necessary.

I believe, and i could be wrong, that the other ports arrange for the
stack pointer to, at least, look as if it was set in the prologue if
in fact it was set before the function is entered.  

Thus, i do not think that this patch is the right way to address this
problem.

kenny

> I noticed this when trying to use DF in md_reorg.  DF_USEs of the
> incoming stack pointer were treated as uses of an uninitialised value.
> (DF seemed to work fine in this context otherwise, which was nice to see.)
> 
> Tested on mips64-linux-gnu and x86_64-linux-gnu.  OK to install?
> 
> TBH, the same ought to be true of the static chain pointer,
> but that isn't tested by my md_reorg stuff.  I can move it too
> if that's preferred.