Re: patch to fix constant math - 4th patch - the wide-int class.

[Mike Stump <mikestump at comcast dot net>]

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.