[PATCH] Revert controversial apply_{args,result}_size change

[Eric Christopher]

On Sun, 2005-04-10 at 22:24 -0700, Mark Mitchell wrote:
> Eric Christopher wrote:
> 
> > 
> > I've gone back to look at some of the original discussion that prompted
> > this patch, most of it came from here:
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00402.html
> 
> I don't entirely follow.
> 
> The current documentation still says:
> 
> "@defmac FUNCTION_VALUE_REGNO_P (@var{regno})
> A C expression that is nonzero if @var{regno} is the number of a hard
> register in which the values of called function may come back.
> 
> A register whose use for returning values is limited to serving as the
> second of a pair (for a value of type @code{double}, say) need not be
> recognized by this macro."
> 

This last part is what doesn't agree with the analogous macro
FUNCTION_ARG_REGNO_P (which you'll agree is highly related to this).

> That seems reasonable enough, although an alternate form in which the 
> second-of-a-pair register *did* have to be recognized would also seem 
> reasonable.  I wouldn't object to switching to that definition -- but 
> the person implementing the switch should go through and update all ports.
> 

Fair enough. I admit that I thought that the two macros had similar
definitions - they're used similarly enough :)

> What seems to have happened is that your change modified the behavior of 
> the API used by back ends, but did not modify the back ends to 
> compensate for that change.  I think we should get back in synch, either 
> by undoing your change, or by updating the back ends.  I don't have a 
> preference as to which approach is taken, though I suspect that undoing 
> your change is easier, in that it probably requires auditing less code.
> 

It would be, and I have no preference (other than that the current
definition makes no sense if you look at it). My change was originally
just going to be for apply_args_size, and does match the definition
there - I just took it across to the similar function.

I'll make either change that's necessary, let's just come to an
agreement on what it should be. I think it should be like
FUNCTION_ARG_REGNO_P.

-eric