Reload patch for 3.1

[David S. Miller]

   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
   Date: Tue, 30 Apr 02 12:53:49 EDT

   As I said, the problem is a SUBREG in an operand with a 'p' constraint.
   'p' sets WIN to 1, intending to say that this can be reloaded.  But the SUBREG
   in this case sets force_reload to say that a reload is necessary.  But WIN
   only clears BADOP if force_reload is not set, and it isn't here.
   
   Since this reload can be done, BADOP should be 0, and should have been set
   to zero at this stop, but it doesn't matter except in the SUBREG case because
   WIN is also set.
   
   I'm pretty sure (and can almost "prove") that this only affects things
   that would presently ICE.  The above argument is essentially a proof
   of that statement.
   
There are very few patterns in the sparc.md file that take
"p" as a constraint, these are:

*tablejump_sp32
*tablejump_sp64
*call_address_sp32
*call_address_sp64
*call_address_struct_value_sp32
*call_address_untyped_struct_value_sp32
*call_value_address_sp32
*call_value_address_sp64
indirect_jump
*branch_sp32
*branch_sp64
prefetch_32
prefetch_64

Can you please show the exact RTL that results in the situation
you run into?

It is really frustrating to analyze any of your Sparc fixes to the
compiler because you can never generate test cases we can add to the
tree and this almost guarentees that these kinds of things will
re-break in the future over and over again until something in the
testsuite can catch it for us.

Yes, I know these are all proprietary Ada programs you use to generate
the failures.  You don't need to reiterate this. I'm in fact sick of
hearing about this exscuse.

Because you've added regressions to the Sparc platform in the past
I'd like to really verify completely that this change is safe before
we consider it.

For example, did both 32-bit and 64-bit Sparc targets show zero
regressions in the testsuite after making this reload change?  How
about other platforms?

I know you've "proved" that only failure cases could hit this
previously, but humans make proofs and humans also make errors :-)

I want you to show us with testsuite results that you really haven't
caused any regressions.