This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH, ppc] Allow IMM8 operands to accept both signed and unsigned values
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Alan Modra" <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>, "Peter Bergner" <bergner at vnet dot ibm dot com>
- Date: Wed, 18 May 2016 03:37:13 -0600
- Subject: Re: [PATCH, ppc] Allow IMM8 operands to accept both signed and unsigned values
- Authentication-results: sourceware.org; auth=none
- References: <1463173058 dot 4256 dot 45 dot camel at vnet dot ibm dot com> <573AEB5B02000078000EBFB6 at prv-mh dot provo dot novell dot com> <20160518023724 dot GI24091 at bubble dot grove dot modra dot org>
>>> On 18.05.16 at 04:37, <amodra@gmail.com> wrote:
> --- a/gas/config/tc-ppc.c
> +++ b/gas/config/tc-ppc.c
> @@ -1787,17 +1787,15 @@ ppc_insert_operand (unsigned long insn,
>
> if ((operand->flags & PPC_OPERAND_SIGNOPT) != 0)
> {
> - /* Extend the allowed range for addis to [-65536, 65535].
> - Similarly for some VLE high part insns. For 64-bit it
> - would be good to disable this for signed fields since the
> + /* Extend the allowed range for addis to [-32768, 65535].
> + Similarly for cmpli and some VLE high part insns. For 64-bit
> + it would be good to disable this for signed fields since the
> value is sign extended into the high 32 bits of the register.
> If the value is, say, an address, then we might care about
> the high bits. However, gcc as of 2014-06 uses unsigned
> values when loading the high part of 64-bit constants using
> - lis.
> - Use the same extended range for cmpli, to allow at least
> - [-32768, 65535]. */
> - min = ~max & -right;
> + lis. */
> + min = ~(max >> 1) & -right;
> }
That's a much appreciated change: With the not so long ago added
addpcis/subpcis I had noticed a similar issue as with the xxspltib now
(and meant to kick off a thread asking for why it's that way there),
and the above change would apparently take care of both then.
The only odd thing left then is that subis is not symmetrical to addis,
while subpcis is wrt addpcis.
Thanks, Jan