On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump <mikestump@comcast.net> wrote:
On Oct 24, 2012, at 2:43 AM, Richard Biener <richard.guenther@gmail.com> wrote:
On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
<zadeck@naturalbridge.com> wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ HOST_WIDE_INT val[2 * MAX_BITSIZE_MODE_ANY_INT /
HOST_BITS_PER_WIDE_INT];
are we sure this rounds properly? Consider a port with max byte mode
size 4 on a 64bit host.
I do not believe that this can happen. The core compiler includes all
modes up to TI mode, so by default we already up to 128 bits.
And mode bitsizes are always power-of-two? I suppose so.
Actually, no, they are not. Partial int modes can have bit sizes that are not power of two, and, if there isn't an int mode that is bigger, we'd want to round up the partial int bit size. Something like ((2 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) / HOST_BITS_PER_WIDE_INT should do it.
I still would like to have the ability to provide specializations of
wide_int
for "small" sizes, thus ideally wide_int would be a template templated
on the number of HWIs in val. Interface-wise wide_int<2> should be
identical to double_int, thus we should be able to do
typedef wide_int<2> double_int;
If you want to go down this path after the patches get in, go for it. I
see no use at all for this.
This was not meant to be a plug in replacement for double int. This goal of
this patch is to get the compiler to do the constant math the way that the
target does it. Any such instantiation is by definition placing some
predefined limit that some target may not want.
Well, what I don't really like is that we now have two implementations
of functions that perform integer math on two-HWI sized integers. What
I also don't like too much is that we have two different interfaces to operate
on them! Can't you see how I come to not liking this? Especially the
latter …
double_int is logically dead. Reactoring wide-int and double-int is a waste of time, as the time is better spent removing double-int from the compiler. All the necessary semantics and code of double-int _has_ been refactored into wide-int already. Changing wide-int in any way to vend anything to double-int is wrong, as once double-int is removed, then all the api changes to make double-int share from wide-int is wasted and must then be removed. The path forward is the complete removal of double-int; it is wrong, has been wrong and always will be wrong, nothing can change that.
double_int, compared to wide_int, is fast and lean. I doubt we will
get rid of it - you
will make compile-time math a _lot_ slower. Just profile when you for example
change get_inner_reference to use wide_ints.
To be able to remove double_int in favor of wide_int requires _at least_
templating wide_int on 'len' and providing specializations for 1 and 2.
It might be a non-issue for math that operates on trees or RTXen due to
the allocation overhead we pay, but in recent years we transitioned important
paths away from using tree math to using double_ints _for speed reasons_.
Richard.