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:55:39 +0100
- Subject: Re: patch to fix constant math -5th patch, rtl
- References: <506C72C7 dot 7090207 at naturalbridge dot com> <50891AAC dot 8090301 at naturalbridge dot com> <CAFiYyc15kmhRWhN3tsZqJDbZ5Uh6tVa45ssiYdsytLEfqaZ4zw at mail dot gmail 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> <871ua0qer8 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc2kotJXQKT8sWu7UXKd5bYccpZKegMajRSt6BesAx-=ZA at mail dot gmail dot com> <87y5c8nhz2 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc15V9NDk2dAJ9kZZ8wwoxts7bEm5eA5Lk8Tk2Erk9LWKg at mail dot gmail dot com> <87fvygngsw dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc0ufm=UFdxgesCxGVV5jO+V-4BJ5nJGLJP6mk8-Wqt=vQ at mail dot gmail dot com> <87txmwm0r9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc297Ev4J5ETxwXM3jQuAjj4Gb20bF2XaUCOgxTdrfF_NA at mail dot gmail dot com>
Richard Biener <firstname.lastname@example.org> writes:
> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
> <email@example.com> wrote:
>> Richard Biener <firstname.lastname@example.org> writes:
>>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>>> <email@example.com> wrote:
>>>> In other words, one of the reasons wide_int can't be exactly 1:1
>>>> in practice is because it is clearing out these mistakes (GEN_INT
>>>> rather than gen_int_mode) and missing features (non-power-of-2 widths).
>>> Note that the argument should be about CONST_WIDE_INT here,
>>> not wide-int. Indeed CONST_WIDE_INT has the desired feature
>>> and can be properly truncated/extended according to mode at the time
>>> we build it
>>> via immed_wide_int_cst (w, mode). I don't see the requirement that
>>> wide-int itself is automagically providing that truncation/extension
>>> (though it is a possibility, one that does not match existing behavior of
>>> HWI for CONST_INT or double-int for CONST_DOUBLE).
>> I agree it doesn't match the existing behaviour of HWI for CONST_INT or
>> double-int for CONST_DOUBLE, but I think that's very much a good thing.
>> The model for HWIs at the moment is that you have to truncate results
>> to the canonical form after every operation where it matters. As you
>> proved in your earlier message about the plus_constant bug, that's easily
>> forgotten. I don't think the rtl code is doing all CONST_INT arithmetic
>> on full HWIs because it wants to: it's doing it because that's the way
>> C/C++ arithmetic on primitive types works. In other words, the current
>> CONST_INT code is trying to emulate N-bit arithmetic (for gcc runtime N)
>> using a single primitive integer type. wide_int gives us N-bit arithmetic
>> directly; no emulation is needed.
> Ok, so what wide-int provides is integer values encoded in 'len' HWI
> words that fit in 'precision' or more bits (and often in less). wide-int
> also provides N-bit arithmetic operations. IMHO both are tied
> too closely together. A give constant doesn't really have a precision.
I disagree. All rtl objects have a precision. REGs, MEMs, SYMBOL_REFs,
LABEL_REFs and CONSTs all have precisions, and the last three are
run-time constants. Why should CONST_INT and CONST_DOUBLE be different?
See e.g. the hoops that cselib has to jump through:
/* We need to pass down the mode of constants through the hash table
functions. For that purpose, wrap them in a CONST of the appropriate
wrap_constant (enum machine_mode mode, rtx x)
if ((!CONST_SCALAR_INT_P (x)) && GET_CODE (x) != CONST_FIXED)
gcc_assert (mode != VOIDmode);
return gen_rtx_CONST (mode, x);
That is, cselib locally converts (const_int X) into (const:M (const_int X)),
purely so that it doesn't lose track of the CONST_INT's mode.
(const:M (const_int ...)) is invalid rtl elsewhere, but a necessary
hack here all the same.
> What RTL currently has looks better to me - operations have
> explicitely specified precisions.
But that isn't enough to determine the precision of all operands.
A classic case is ZERO_EXTEND. Something like:
(zero_extend:DI (reg:SI X))
is unambiguous. But if you substitute (reg:SI X) with a CONST_INT,
the result becomes ambiguous. E.g. we could end up with:
(zero_extend:DI (const_int -1))
The ZERO_EXTEND operand still has SImode, but that fact is not explicit
in the rtl, and is certainly not explicit in the ZERO_EXTEND operation.
So if we just see the result above, we no longer know whether the result
should be (const_int 0xff), (const_int 0xffff), or what. The same goes for:
(zero_extend:DI (const_int 256))
where (const_int 0) and (const_int 256) are both potential results.
It's not just ZERO_EXTEND. E.g.:
tells you that an SImode value is being extracted, but it doesn't tell
you what precision you're extracting from. So for:
(zero_extract:SI (const_int -1) (const_int X) (const_int 3))
how many 1 bits should be the result have? Because of the sign-extension
canonicalisation, the answer depends on the precision of the (const_int -1),
which has now been lost. If instead CONST_INTs were stored in zero-extended
form, the same ambiguity would apply to SIGN_EXTRACT.
This sort of thing has been a constant headache in rtl. I can't stress
how much I feel it is _not_ better than recording the precision of
the constant :-)