[RFC] HOST_WIDE_INT transition steps

[RFC] HOST_WIDE_INT transition steps

[Richard Biener]

The following is my current idea on progressing on the HOST_WIDE_INT
removal

1) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00381.html (ping)

2) make sure [u]int64_t is available and use that to define HOST_WIDE_INT

3) s/HOST_WIDE_INT/int64_t/ (same for unsigned HOST_WIDE_INT)

Leaves us with HOST_WIDEST_INT (just use [u]int64_t, I don't think
we care for 128bit types).  And HOST_WIDEST_FAST_INT for which
I don't have a very good suggestion other than either keeping
it, unconditionally using 'long' (thus simply remove
use_long_long_for_widest_fast_int and handling).  The fast_[u]int64_t
types and friends don't seem to be very "useful".

Any comments?

Thanks,
Richard.

Re: [RFC] HOST_WIDE_INT transition steps

[Richard Sandiford]

Richard Biener <rguenther@suse.de> writes:
> The following is my current idea on progressing on the HOST_WIDE_INT
> removal
>
> 1) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00381.html (ping)
>
> 2) make sure [u]int64_t is available and use that to define HOST_WIDE_INT
>
> 3) s/HOST_WIDE_INT/int64_t/ (same for unsigned HOST_WIDE_INT)
>
> Leaves us with HOST_WIDEST_INT (just use [u]int64_t, I don't think
> we care for 128bit types).

All sounds good to me FWIW.

There'll probably be plenty of references to "HWI", "hwint", etc.
as well...

> And HOST_WIDEST_FAST_INT for which
> I don't have a very good suggestion other than either keeping
> it, unconditionally using 'long' (thus simply remove
> use_long_long_for_widest_fast_int and handling).  The fast_[u]int64_t
> types and friends don't seem to be very "useful".

long isn't very good for ABIs like x86_64 x32 and MIPS n32, where the
registers are wider than long.

I don't see anything wrong with leaving it for now.  If we get rid of
HOST_WIDE_INT and HOST_WIDEST_INT then that's plenty of progress on
its own.

Thanks,
Richard

Re: [RFC] HOST_WIDE_INT transition steps

[Mikael Pettersson]

Richard Biener writes:
 > 
 > The following is my current idea on progressing on the HOST_WIDE_INT
 > removal
...
 > And HOST_WIDEST_FAST_INT for which
 > I don't have a very good suggestion other than either keeping
 > it, unconditionally using 'long' (thus simply remove
 > use_long_long_for_widest_fast_int and handling).  The fast_[u]int64_t
 > types and friends don't seem to be very "useful".
 > 
 > Any comments?

Hard-coding long will probably be problematic for builds on hosts with
sizeof(long) < sizeof(void*), e.g. x86_64-w64-mingw32.  There you really
need to use *int64_t or long long.

/Mikael

Re: [RFC] HOST_WIDE_INT transition steps

[Eric Botcazou]

> The following is my current idea on progressing on the HOST_WIDE_INT
> removal
> 
> 1) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00381.html (ping)
> 
> 2) make sure [u]int64_t is available and use that to define HOST_WIDE_INT
> 
> 3) s/HOST_WIDE_INT/int64_t/ (same for unsigned HOST_WIDE_INT)

Does 3) really buy us something?  That would make backports painful I think.

-- 
Eric Botcazou

Re: [RFC] HOST_WIDE_INT transition steps

[Richard Biener]

On Tue, 20 May 2014, Eric Botcazou wrote:

> > The following is my current idea on progressing on the HOST_WIDE_INT
> > removal
> > 
> > 1) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00381.html (ping)
> > 
> > 2) make sure [u]int64_t is available and use that to define HOST_WIDE_INT
> > 
> > 3) s/HOST_WIDE_INT/int64_t/ (same for unsigned HOST_WIDE_INT)
> 
> Does 3) really buy us something?  That would make backports painful I think.

Same as for going C++.  Make the code base easier to understand for
newcomers.  It's also a documentation improvement (you see what
a HOST_WIDE_INT really is), alongside with [u]int64_t being less
to type ...

Btw, all of the current pending rewrite patches will make backports
painful.  Oh well.

Richard.

Re: [RFC] HOST_WIDE_INT transition steps

[Eric Botcazou]

> Same as for going C++.

Not to the same extent, this will be worse because done en masse throughout 
the code instead of gradually.

> Make the code base easier to understand for newcomers.  It's also a
> documentation improvement (you see what a HOST_WIDE_INT really is),
> alongside with [u]int64_t being less to type ...

I personally find the abstraction and the separation with the other, more 
mundane types useful, but I guess that it's a matter of habit.

-- 
Eric Botcazou

Re: [RFC] HOST_WIDE_INT transition steps

[Richard Biener]

On Tue, 20 May 2014, Eric Botcazou wrote:

> > Same as for going C++.
> 
> Not to the same extent, this will be worse because done en masse throughout 
> the code instead of gradually.

Like the gimple -> gimple * change pending or the various
gimple -> gswitch,glabel,etc. stuff?  It's on a similar scale at lest.

> > Make the code base easier to understand for newcomers.  It's also a
> > documentation improvement (you see what a HOST_WIDE_INT really is),
> > alongside with [u]int64_t being less to type ...
> 
> I personally find the abstraction and the separation with the other, more 
> mundane types useful, but I guess that it's a matter of habit.

Yeah.  I'm happy of converting only "obvious" cases (or converting
them separately at least).  Of course there may be not that many
decoupled pieces ...

Richard.

Re: [RFC] HOST_WIDE_INT transition steps

[Joseph S. Myers]

On Tue, 20 May 2014, Eric Botcazou wrote:

> > Make the code base easier to understand for newcomers.  It's also a
> > documentation improvement (you see what a HOST_WIDE_INT really is),
> > alongside with [u]int64_t being less to type ...
> 
> I personally find the abstraction and the separation with the other, more 
> mundane types useful, but I guess that it's a matter of habit.

Whatever the abstraction is, HOST_WIDE_INT is a pretty poor name for it.  
I think it's something like "integer type that is big enough to store a 
target address / offset in bytes, or a target word", together with a sense 
of "integer type big enough for certain constants and such that twice it 
is big enough for other constants" (the latter being what wide-int should 
enable eliminating eventually).

But I suspect HOST_WIDE_INT is used for lots of other things as well - and 
for things for which 64 bits may not be enough (bit offsets, for example), 
and for that matter int is used for things for which HOST_WIDE_INT would 
be more appropriate (the length of a STRING_CST, for example).  So while 
there may be a meaningful abstraction somewhere in there, I don't think 
the particular places that happen to use HOST_WIDE_INT are a very good 
guide to where such an abstraction should be used - and don't think moving 
to int64_t / uint64_t would actually lose information of use for cleaning 
things up in future.

(HOST_WIDEST_INT should of course become intmax_t.  It should also not be 
used in any way that can affect code generation.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] HOST_WIDE_INT transition steps

[Richard Sandiford]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> On Tue, 20 May 2014, Eric Botcazou wrote:
>> > Make the code base easier to understand for newcomers.  It's also a
>> > documentation improvement (you see what a HOST_WIDE_INT really is),
>> > alongside with [u]int64_t being less to type ...
>> 
>> I personally find the abstraction and the separation with the other, more 
>> mundane types useful, but I guess that it's a matter of habit.
>
> Whatever the abstraction is, HOST_WIDE_INT is a pretty poor name for it.  
> I think it's something like "integer type that is big enough to store a 
> target address / offset in bytes, or a target word", together with a sense 
> of "integer type big enough for certain constants and such that twice it 
> is big enough for other constants" (the latter being what wide-int should 
> enable eliminating eventually).
>
> But I suspect HOST_WIDE_INT is used for lots of other things as well - and 
> for things for which 64 bits may not be enough (bit offsets, for example), 
> and for that matter int is used for things for which HOST_WIDE_INT would 
> be more appropriate (the length of a STRING_CST, for example).  So while 
> there may be a meaningful abstraction somewhere in there, I don't think 
> the particular places that happen to use HOST_WIDE_INT are a very good 
> guide to where such an abstraction should be used - and don't think moving 
> to int64_t / uint64_t would actually lose information of use for cleaning 
> things up in future.

Same here FWIW.  And int64_t and uint64_t have the advantage of being
"proper" types rather than #defines, which has caused surprises in the past.
(E.g. a case where HOST_WIDE_INT (x) worked for most hosts but not mingw64.)

We wouldn't be able to get away from using the #define without also
replacing "unsigned HOST_WIDE_INT" with something else, which wouldn't
be much less invasive than replacing all HOST_WIDE_INTs.  And I can't
help thinking that people have used HOST_WIDE_INT not because they
needed a signed type with undefined overflow, but because it was less
to type.

Richard