* [RFC] HOST_WIDE_INT transition steps
@ 2014-05-19 12:45 Richard Biener
2014-05-19 18:55 ` Richard Sandiford
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Richard Biener @ 2014-05-19 12:45 UTC (permalink / raw)
To: gcc-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-19 12:45 [RFC] HOST_WIDE_INT transition steps Richard Biener
@ 2014-05-19 18:55 ` Richard Sandiford
2014-05-20 7:20 ` Mikael Pettersson
2014-05-20 11:03 ` Eric Botcazou
2 siblings, 0 replies; 9+ messages in thread
From: Richard Sandiford @ 2014-05-19 18:55 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-19 12:45 [RFC] HOST_WIDE_INT transition steps Richard Biener
2014-05-19 18:55 ` Richard Sandiford
@ 2014-05-20 7:20 ` Mikael Pettersson
2014-05-20 11:03 ` Eric Botcazou
2 siblings, 0 replies; 9+ messages in thread
From: Mikael Pettersson @ 2014-05-20 7:20 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-19 12:45 [RFC] HOST_WIDE_INT transition steps Richard Biener
2014-05-19 18:55 ` Richard Sandiford
2014-05-20 7:20 ` Mikael Pettersson
@ 2014-05-20 11:03 ` Eric Botcazou
2014-05-20 11:14 ` Richard Biener
2 siblings, 1 reply; 9+ messages in thread
From: Eric Botcazou @ 2014-05-20 11:03 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-20 11:03 ` Eric Botcazou
@ 2014-05-20 11:14 ` Richard Biener
2014-05-20 11:23 ` Eric Botcazou
0 siblings, 1 reply; 9+ messages in thread
From: Richard Biener @ 2014-05-20 11:14 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-20 11:14 ` Richard Biener
@ 2014-05-20 11:23 ` Eric Botcazou
2014-05-20 11:25 ` Richard Biener
2014-05-20 15:15 ` Joseph S. Myers
0 siblings, 2 replies; 9+ messages in thread
From: Eric Botcazou @ 2014-05-20 11:23 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-20 11:23 ` Eric Botcazou
@ 2014-05-20 11:25 ` Richard Biener
2014-05-20 15:15 ` Joseph S. Myers
1 sibling, 0 replies; 9+ messages in thread
From: Richard Biener @ 2014-05-20 11:25 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-20 11:23 ` Eric Botcazou
2014-05-20 11:25 ` Richard Biener
@ 2014-05-20 15:15 ` Joseph S. Myers
2014-05-22 11:24 ` Richard Sandiford
1 sibling, 1 reply; 9+ messages in thread
From: Joseph S. Myers @ 2014-05-20 15:15 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Richard Biener, gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] HOST_WIDE_INT transition steps
2014-05-20 15:15 ` Joseph S. Myers
@ 2014-05-22 11:24 ` Richard Sandiford
0 siblings, 0 replies; 9+ messages in thread
From: Richard Sandiford @ 2014-05-22 11:24 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Eric Botcazou, Richard Biener, gcc-patches
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-05-22 11:24 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-19 12:45 [RFC] HOST_WIDE_INT transition steps Richard Biener
2014-05-19 18:55 ` Richard Sandiford
2014-05-20 7:20 ` Mikael Pettersson
2014-05-20 11:03 ` Eric Botcazou
2014-05-20 11:14 ` Richard Biener
2014-05-20 11:23 ` Eric Botcazou
2014-05-20 11:25 ` Richard Biener
2014-05-20 15:15 ` Joseph S. Myers
2014-05-22 11:24 ` Richard Sandiford
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).