This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1


Richard Biener <richard.guenther@gmail.com> writes:
> Richard Sandiford <rdsandiford@googlemail.com> wrote:
>>Richard Biener <richard.guenther@gmail.com> 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
>>constants" :-)
>>
>>> +#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.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]