This is the mail archive of the 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 -5th patch, rtl

On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
<> wrote:
> Richard Biener <> writes:
>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>> <> 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.
Associating one with it to give a precision to an arithmetic operation
looks wrong to me and are a source of mismatches.

What RTL currently has looks better to me - operations have
explicitely specified precisions.

> If your point is that an arbitrary-precision wide_int could be used by
> other (non-rtl, and probably non-tree) clients, then I don't really
> see the need.  We already have mpz_t for that.  What we don't have,
> and what we IMO need, is something that performs N-bit arithmetic
> for runtime N.  It seems better to have a single class that does
> that for us (wide_int), rather than scatter N-bit emulation throughout
> the codebase, which is what we do now.

mpz_t is not suitable here - it's way too expensive.  double-int
was the "suitable" bit for now, but given it's host dependency and
inability to handle larger ints (VRP ...) the ability to use wide-ints
for this looks appealing.


> Richard

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