This is the mail archive of the
mailing list for the GCC project.
Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 29 May 2014 09:13:35 -0700
- Subject: Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoEako44t7Z27JQAjG_eWS0hCWbrhOMyy1fLqmjLZqhbw at mail dot gmail dot com> <4E18C5BE dot 6020809 at gnu dot org> <CAMe9rOo=U6wkp10oUD=p-z8p71FUDbVxvpyCPB9VdBhiNxp9+Q at mail dot gmail dot com> <CAHFMJ7s__5YDq=i8Wsg-yKMM9qpN7tKrVW9hkhphynQH6ktabg at mail dot gmail dot com> <CAMe9rOr9WpkWv_uW1sTN5XZyoJpGuR4B-K1uEFHDrFfVMUk5LQ at mail dot gmail dot com> <CAMe9rOrvq0CeiD+RE-Bg09c0bapudHny01Q4n7+moOQeKtB2vA at mail dot gmail dot com> <CAMe9rOr2J8fy+nSmHAusRNaYSU1Z8X2R9pgRDO1Q_T98qwczyg at mail dot gmail dot com> <4E1AD86A dot 8000800 at gnu dot org> <CAMe9rOp7=UvknX2z9k5O1Q8sJkXH8Z11=7TEjU0M5_EoAFC11g at mail dot gmail dot com> <4E1DC42D dot 1010307 at gnu dot org> <CAMe9rOqvtxTAh389kj8N7FySC7WN5jxVYomGwtx+69e01nxDZA at mail dot gmail dot com> <CA+=Sn1njPanPBzH-6B5DcVz4r3e0nBQMwPenQ+5GE3p-at2adw at mail dot gmail dot com>
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski <email@example.com> wrote:
> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu <firstname.lastname@example.org> wrote:
>> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini <email@example.com> wrote:
>>> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>>>> The key is the
>>>> > XEXP (x, 1) == convert_memory_address_addr_space
>>>> > (to_mode, XEXP (x, 1), as)
>>>> > test. It ensures basically that the constant has 31-bit precision,
>>>> > because
>>>> > otherwise the constant would change from e.g. (const_int -0x7ffffffc)
>>>> > to
>>>> > (const_int 0x80000004) when zero-extending it from SImode to DImode.
>>>> > But I'm not sure it's safe. You have,
>>>> > (zero_extend:DI (plus:SI FOO:SI) (const_int Y))
>>>> > and you want to convert it to
>>>> > (plus:DI FOO:DI (zero_extend:DI (const_int Y)))
>>>> > (where the zero_extend is folded). Ignore that FOO is a SYMBOL_REF
>>>> > (this
>>>> > piece of code does not assume anything about its shape); if FOO ==
>>>> > 0xfffffffc and Y = 8, the result will be respectively 0x4 (valid) and
>>>> > 0x100000004 (invalid).
>>>> This example contradicts what you said above "It ensures basically that
>>>> constant has 31-bit precision".
>>> Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
>>> representation in SImode and DImode, and the test above on XEXP (x, 1)
>> And then we permute conversion and addition, which leads to the issue you
>> raised above. In another word, the current code permutes conversion
>> and addition.
>> It leads to different values in case of symbol (0xfffffffc) + 8.
>> Basically the current
>> test for 31-bit (or less) precision is bogus. The real question is
>> for a address
>> computation, A + B, if address wrap-around is supported in
> Unless the code has already reassociated the additions already.
> Like in the AARCH64 ILP32 case:
> (plus:SI (plus:SI (mult:SI (reg/v:SI 80 [ b ])
> (const_int -4 [0xfffffffffffffffc]))
> (subreg/s/u:SI (reg/v/f:DI 79 [ a ]) 0))
> (const_int -1073742592 [0xffffffffbffffd00]))
> The Tree level is correct in that it did not reassociate the addition
> but the RTL level ignores that.
> So this patch is invalid and incorrect unless you know the non
> constant part of the addition is a pointer (which is not the case
There is an address overflow. Is the address overflow behavior