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.
