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 -5th patch, rtl


Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
> <rdsandiford@googlemail.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.

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.

Richard


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