This is the mail archive of the
gcc-patches@gcc.gnu.org
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 13:44:59 +0100
- Subject: Re: patch to fix constant math -5th patch, rtl
- References: <506C72C7 dot 7090207 at naturalbridge dot com> <CAFiYyc1=8=LffiZ=EDBOy_uzn_ARdXk1OWxT=abYd8ot+iFp5Q at mail dot gmail 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> <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> <CAFiYyc3P8sFfFQT95yr_UZSOs-JOUefvCm0bxQe1ZSUDgcMg_A at mail dot gmail dot com>
Richard Biener <richard.guenther@gmail.com> 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 sign-extended
from mode precision to HWI precision. The 8-bit value 0xb10000000 must be
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.
> What does wide-int do with VOIDmode mode inputs?
> It seems to ICE on them for from_rtx and use garbage (0) for from_shwi. Ugh.
ICEing is right. As mentioned before, every rtx constant has a mode,
whether it's stored in the rtx or not. Callers must keep track of
what that mode is.
> Btw, plus_constant asserts that mode is either VOIDmode (I suppose
> semantically do "arbitrary precision")
No, not arbitrary precision. It's always the precision specified
by the "mode" parameter. The assert is:
gcc_assert (GET_MODE (x) == VOIDmode || GET_MODE (x) == mode);
This is because GET_MODE always returns VOIDmode for CONST_INT and
CONST_DOUBLE integers. The mode parameter is needed to tell us what
precision those CONST_INTs and CONST_DOUBLEs actually have, because
the rtx itself doesn't tell us. The mode parameter serves no purpose
beyond that.
So if the rtx does specify a mode (everything except CONST_INT and
CONST_DOUBLE), the assert is making sure that the caller has correctly
tracked the rtx's mode and provided the right mode parameter. The caller
must do that for all rtxes, it's just that we can't assert for it in the
CONST_INT and CONST_DOUBLE case, because the rtx has no mode to check
against. If CONST_INT and CONST_DOUBLE did have a mode to check against,
there would be no need for the mode parameter at all. Likewise there
would be no need for wide_int::from_rtx to have a mode parameter.
Richard