Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

[Richard Sandiford <rdsandiford at googlemail dot com>]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> I would like you to respond to at least point 1 of this email.   In it 
> there is code from the rtl level that was written twice, once for the 
> case when the size of the mode is less than the size of a HWI and once 
> for the case where the size of the mode is less that 2 HWIs.
>
> my patch changes this to one instance of the code that works no matter 
> how large the data passed to it is.
>
> you have made a specific requirement for wide int to be a template that 
> can be instantiated in several sizes, one for 1 HWI, one for 2 HWI.   I 
> would like to know how this particular fragment is to be rewritten in 
> this model?   It seems that I would have to retain the structure where 
> there is one version of the code for each size that the template is 
> instantiated.

I think richi's argument was that wide_int should be split into two.
There should be a "bare-metal" class that just has a length and HWIs,
and the main wide_int class should be an extension on top of that
that does things to a bit precision instead.  Presumably with some
template magic so that the length (number of HWIs) is a constant for:

  typedef foo<2> double_int;

and a variable for wide_int (because in wide_int the length would be
the number of significant HWIs rather than the size of the underlying
array).  wide_int would also record the precision and apply it after
the full HWI operation.

So the wide_int class would still provide "as wide as we need" arithmetic,
as in your rtl patch.  I don't think he was objecting to that.

As is probably obvious, I don't agree FWIW.  It seems like an unnecessary
complication without any clear use.  Especially since the number of
significant HWIs in a wide_int isn't always going to be the same for
both operands to a binary operation, and it's not clear to me whether
that should be handled in the base class or wide_int.

Richard