This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE
- From: Michael Matz <matz at suse dot de>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jim Wilson <jim dot wilson at linaro dot org>, Jeff Law <law at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 15 Jul 2015 14:57:54 +0200 (CEST)
- Subject: Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE
- Authentication-results: sourceware.org; auth=none
- References: <CABXYE2VXjy7=5Y=c1TCxLE8KuwLtwBYBhTB24xrWDvWAeiBwbQ at mail dot gmail dot com> <559BEB2D dot 7040800 at redhat dot com> <CABXYE2UbBP24fBEgDJp5+S1fhFpNHPJgjM=SypsWbc4hV1xbbw at mail dot gmail dot com> <DDEC7CC8-74EE-4ACF-97C8-EE5A7D53CDB6 at gmail dot com> <CABXYE2X4OhMvyK-z+yQvDkcT0TgKUc2Nv+YdhXWZnJDNDMeJqg at mail dot gmail dot com> <CAFiYyc1M4OqAs9tEhNObnXyC6xsBtFE8XeMrGPV1WoCc-VKY-g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1507131651560 dot 23227 at wotan dot suse dot de> <55A53519 dot 6040305 at foss dot arm dot com>
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.