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 ping


Hello,

> On Tue, Feb 21, 2006 at 04:43:17PM +0100, Zdenek Dvorak wrote:
> > yes, this is about the only real advantage of the representation (b).
> 
> The fact that rtl uses (b) for its const_int lends support for using
> that representation elsewhere.  It's surely less confusing to have 
> one rule instead of two.

rtl (function immed_double_const) usses the following rules:
the function takes two HOST_WIDE_INTs i0 and i1 (where i1 corresponds to higher
bits).  Let w be precision of the mode of the constructed constant, and
s the sign bit of the represented number (i.e. the one at position
1 << (w - 1)).

If w <= HOST_BITS_PER_WIDE_INT, the functions returns just CONST_INT, not
CONST_DOUBLE.  In this case, rule (b) -- filling bits above w with s --
is used.

Suppose now w > HOST_BITS_PER_WIDE_INT.  If i1 == 0 and i0 >=0, or
i1 == -1 and i1 < 0, we return CONST_INT for i0, anyway.

Otherwise, the components i0 and i1 are put into the constant unchanged.

In particular, this means that the rtl semantics allows multiple
representations for the same number, in case
HOST_BITS_PER_WIDE_INT < w < 2 * HOST_BITS_PER_WIDE_INT.

I do not really have very strong preferences whether to use semantics
(a) or (b), as long as we do not use the semantics we use for rtl :-)
I slightly prefer (a), as

1) normalization is slightly simpler
2) it is the more senseful one if the components of double_int are
   manipulated as unsigned numbers (which I prefer as it makes it
   less likely to run into problems with undefined semantics of
   overflow for signed types).

Zdenek


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