This is the mail archive of the
mailing list for the GCC project.
Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1
- 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: Mon, 22 Apr 2013 23:00:23 +0100
- Subject: Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1
- 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> <CAFiYyc3fXewAW2dU6-RHLiTQ-ZiLgdWmfwdFF6k1VqxPsrvZbQ at mail dot gmail dot com> <515B16EB dot 5020303 at naturalbridge dot com> <CAFiYyc2qWwDcqzCMpMSiQ72w5ry=a3ZpxkFkiK7OvvBA0h4eGw at mail dot gmail dot com> <515C1AFB dot 3080105 at naturalbridge dot com> <CAFiYyc12qGj92j+5yCUEpghOZXqjjAgOzS_H6QJpKvd-dyfU0A at mail dot gmail dot com> <515C55D7 dot 7020003 at naturalbridge dot com> <CAFiYyc0sp1wbq1J+FXoJWcb9UcsOWiwjJ_KaQkbbgCnddxhVzA at mail dot gmail dot com> <87y5cajqxu dot fsf at talisman dot default> <5985e061-876c-46f1-bdb0-a686d47eb9d3 at email dot android dot com>
Richard Biener <firstname.lastname@example.org> writes:
> Richard Sandiford <email@example.com> wrote:
>>Richard Biener <firstname.lastname@example.org> writes:
>>>> At the rtl level your idea does not work. rtl constants do not
>>have a mode
>>>> or type.
>>> Which is not true and does not matter. I tell you why. Quote:
>>It _is_ true, as long as you read "rtl constants" as "rtl integer
>>> +#if TARGET_SUPPORTS_WIDE_INT
>>> +/* Match CONST_*s that can represent compile-time constant integers.
>>> +#define CASE_CONST_SCALAR_INT \
>>> + case CONST_INT: \
>>> + case CONST_WIDE_INT
>>> which means you are only replacing CONST_DOUBLE with wide-int.
>>> And _all_ CONST_DOUBLE have a mode. Otherwise you'd have no
>>> way of creating the wide-int in the first place.
>>No, integer CONST_DOUBLEs have VOIDmode, just like CONST_INT.
>>Only floating-point CONST_DOUBLEs have a "real" mode.
> I stand corrected. Now that's one more argument for infinite precision
> constants, as the mode is then certainly provided by the operations
> similar to the sign. That is, the mode (or size, or precision) of 1
> certainly does not matter.
I disagree. Although CONST_INT and CONST_DOUBLE don't _store_ a mode,
they are always interpreted according to a particular mode. It's just
that that mode has to be specified separately. That's why so many
rtl functions have (enum machine_mode, rtx) pairs.
Infinite precision seems very alien to rtl, where everything is
interpreted according to a particular mode (whether that mode is
stored in the rtx or not).
For one thing, I don't see how infinite precision could work in an
environment where signedness often isn't defined. E.g. if you optimise
an addition of two rtl constants, you don't know (and aren't supposed
to know) whether the values involved are "signed" or "unsigned". With
fixed-precision arithmetic it doesn't matter, because both operands must
have the same precision, and because bits outside the precision are not
significant. With infinite precision arithmetic, the choice carries
over to the next operation. E.g., to take a 4-bit example, you don't
know when constructing a wide_int from an rtx whether 0b1000 represents
8 or -8. But if you have no precision to say how many bits are significant,
you have to pick one. Which do you choose? And why should we have to
make a choice at all? (Note that this is a different question to
whether the internal wide_int representation is sign-extending or not,
which is purely an implementation detail. The same implementation
principle applies to CONST_INTs: the HWI in a CONST_INT is always
sign-extended from the msb of the represented value, although of course
the CONST_INT itself doesn't tell you which bit the msb is; that has to
be determined separately.)
A particular wide_int isn't, and IMO shouldn't be, inherently signed
or unsigned. The rtl model is that signedness is a question of
interpretation rather than representation. I realise trees are
different, because signedness is a property of the type rather
than operations on the type, but I still think fixed precision
works with both tree and rtl whereas infinite precision doesn't
work with rtl.
I also fear there are going to be lots of bugs where we forget to
truncate the result of an N-bit operation from "infinite" precision
to N bits before using it in the next operation (as per Kenny's ring
explanation). With finite precision, and with all-important asserts
that the operands have consistent precisions, we shouldn't have any
hidden bugs like that.
If there are parts of gcc that really want to do infinite-precision
arithmetic, mpz_t ought to be as good as anything.