[PATCH, ARM] stop changing signedness in PROMOTE_MODE

[Michael Matz]

Hi,

On Tue, 14 Jul 2015, Richard Earnshaw wrote:

> > I think it's a backend bug that parameters and locals are extended 
> > differently.  The code in tree-outof-ssa was written with the 
> > assumption that the modes of RTL objects might be different (larger) 
> > than the tree types suggest, but that they be _consistent_, i.e. that 
> > the particular extension depends on only the types, not on the 
> > tree-type of the decl.
> 
> We went through this a couple of weeks back.  The backend documentation 
> for PROMOTE_MODE says:
> 
> " For most machines, the macro definition does not change 
> @var{unsignedp}. However, some machines, have instructions that 
> preferentially handle either signed or unsigned quantities of certain 
> modes.  For example, on the DEC Alpha, 32-bit loads from memory and 
> 32-bit add instructions sign-extend the result to 64 bits.  On such 
> machines, set @var{unsignedp} according to which kind of extension is 
> more efficient."

We aren't talking about what PROMOTE_MODE is or is not allowed, but about 
an inconsistency between what PROMOTE_MODE does and what 
target.promote_function_mode does.  This is quite clearly a historic 
accident in the ARM port, namely that they extend parameters and locals in 
opposite ways, which originally wasn't even possible to describe in GCC.

> So clearly it anticipates that all permitted extensions should work, and 
> in particular it makes no mention of this having to match some 
> abi-mandated promotions.  That makes this a MI bug not a target one.

All extensions do work just fine, except when the LHS and RHS of a copy 
instruction with the same types require different extension types 
depending on if the rhs is a PARM_DECL or not.  It's also fundamental in 
gimple that copies can't change signedness, and this insonsistency breaks 
that assumption.  Jim says that this is actually harmless in reality, 
because even a copy propagation will at most replace a use of a VAR_DECL 
with a PARM_DECL, and at the point of such use the other promotion would 
be added by expand.  While the latter is true, I haven't really convinced 
myself that this really leads to correct code in all cases.


Ciao,
Michael.