Re: [arm, patch] Remove redundant promotion of function arguments

[Paul Brook <paul at codesourcery dot com>]

> Err, wait a minute.
>
> defined (PROMOTE_FOR_CALL_ONLY) != not defined (PROMOTE_MODE).

Yes.

> There were three cases in the old logic
>
> 1) Nothing defined
> 2) PROMOTE_MODE defined and PROMOTE_FOR_CALL_ONLY defined
> 3) PROMOTE_MODE defined
>
> In the new logic the equivalents are now
>
> 1) Nothing defined
> 2) PROMOTE_FUNCTION_MODE defined
> 3) PROMOTE_MODE defined and PROMOTE_FUNCTION_MODE defined

Actually this is:
3) only PROMOTE_MODE defined
4) [new] PROMOTE_MODE defined and PROMOTE_FUNCTION_MODE defined

So code for the old (2) could now also apply to (4), if it deals with cases 
where arguments and locals are promoted differently. The new case (3) should 
produce the same code as defining both macros to the same value.

I think the code is safe for (2), safe but useless for (1), unsure about (3) 
and unsafe for (4). I suspect it may be worthwhile to add similar code for 
case (4), however I don't fully understand the purpose of the code, and 
haven't yet found a case where it affects the generated code.

It is valid (but pointless) to define either or both of PROMOTE_MODE and 
PROMOTE_FUNCTON_MODE to a nop. All code must always be safe for case (1).

I suggest that the proper condition in calls.c is
defined(PROMOTE_FUNCTION_MODE) && !defined (PROMOTE_MODE)

Does this sound reasonable?

> So your change means that code in category 1 is now being treaded as
> though it was in category 2.  This might, or might not, be OK in all

Isn't this the other way round? Code that was previously run only for 2 is now 
run for both 1 and 2.

> circumstances.  In the case of your change to calls.c I think it is
> probably not.

I think it is ok, but inefficient. I suspect the code will never actually be 
executed in case (1).

Paul