This is the mail archive of the
mailing list for the GCC project.
Re: patch to fix constant math -5th patch, rtl
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Kenneth Zadeck <zadeck at naturalbridge dot com>, Mike Stump <mikestump at comcast dot net>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Lawrence Crowl <crowl at google dot com>, Ian Lance Taylor <iant at google dot com>
- Date: Wed, 24 Apr 2013 16:29:56 +0100
- Subject: Re: patch to fix constant math -5th patch, rtl
- References: <506C72C7 dot 7090207 at naturalbridge dot com> <87y5im3orb dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc2buJtu8RMKnLnvvb-A2=aYwopO+RBLPO6iJ3gKnq-hvg at mail dot gmail dot com> <87pq3y3kyk dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc3NjOxpQ-Y9GDrQOET+dc3LXWuiuM=DxqmyASE8urRoWw at mail dot gmail dot com> <50912D85 dot 1070002 at naturalbridge dot com> <CAFiYyc2Q2UQPmkhExi2c8f-BSGLv+Rq1rOy4NdPQmTqSRE1A0A at mail dot gmail dot com> <5091331C dot 3030504 at naturalbridge dot com> <CAFiYyc1L6zuehE75dEfd_fB1-81F1fDHpL3kS=tbk6qAK3Texg at mail dot gmail dot com> <512D686B dot 90000 at naturalbridge dot com> <515EC4E7 dot 7040907 at naturalbridge dot com> <CAFiYyc3x6xb16kbYB9LzcC+XX17hM=R-h9KEWCZy6o0k-Csjfw at mail dot gmail dot com> <516DAF9B dot 3050008 at naturalbridge dot com> <516DB1F3 dot 8090908 at naturalbridge dot com> <871ua0qer8 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc2kotJXQKT8sWu7UXKd5bYccpZKegMajRSt6BesAx-=ZA at mail dot gmail dot com> <5177ED9A dot 7000807 at naturalbridge dot com> <CAFiYyc1u5+3HBcNUmGq060n7G2VZ1FjJpeswn7ERAb2Z71oOBQ at mail dot gmail dot com>
Richard Biener <email@example.com> writes:
> On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
> <firstname.lastname@example.org> wrote:
>> On 04/24/2013 09:36 AM, Richard Biener wrote:
>>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>>> <email@example.com> wrote:
>>>> Richard Biener <firstname.lastname@example.org> writes:
>>>>> Can we in such cases please to a preparatory patch and change the
>>>>> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
>>>>> mode precision first?
>>>> I'm not sure what you mean here. CONST_INT HWIs are already
>>>> from mode precision to HWI precision. The 8-bit value 0xb10000000 must
>>>> represented as (const_int -128); nothing else is allowed. E.g.
>>>> (const_int 128)
>>>> is not a valid QImode value on BITS_PER_UNIT==8 targets.
>>> Yes, that's what I understand. But consider you get a CONST_INT that is
>>> _not_ a valid QImode value. Current code simply trusts that it is, given
>>> the context from ...
>> And the fact that it we have to trust but cannot verify is a severe problem
>> at the rtl level that is not going to go away. what i have been strongly
>> objecting to is your idea that just because we cannot verify it, we can thus
>> go change it in some completely different way (i.e. the infinite precision
>> nonsense that you keep hitting us with) and it will all be ok.
> Appearantly it is all ok because that's exactly what we have today (and
> had for the last 25 years). CONST_INT encodes infinite precision signed
> values (with the complication that a QImode 0x80 isn't valid, thus all
> modes are signed as well it seems).
I think this is the fundamental disagreement. Your last step doesn't
follow. RTL integer modes are neither signed nor unsigned. They are
just a collection of N bits. The fact that CONST_INTs represent
smaller-than-HWI integers in sign-extended form is purely a represential
detail. There are no semantics attached to it. We could just as easily
have decided to extend with zeros or ones instead of sign bits.
Although the decision was made before my time, I'm pretty sure the
point of having a canonical representation (which happened to be sign
extension) was to make sure that any given rtl constant has only a
single representation. It would be too confusing if a QImode 0x80 could
be represented as either (const_int 128) or (const_int -128) (would
(const_int 384) then also be OK?).
And that's the problem with using an infinite-precision wide_int.
If you directly convert a CONST_INT representation of 0x80 into a
wide_int, you will always get infinite-precision -128, thanks to the
CONST_INT canonicalisation rule. But if you arrive at 0x80 though
arithmetic, you might get infinite-precision 128 instead. These two
values would not compare equal.
> CONST_DOUBLE encodes infinite precision signed values as well. Just
> the "infinite" is limited by the size of the encoding, one and two
It encodes an N-bit integer. It's just that (assuming non-power-of-2
modes) several N-bit integers (with varying N) can be encoded using the
same CONST_DOUBLE representation. That might be what you meant, sorry,
and so might seem pedantic, but I wasn't sure.