Re: wide-int branch now up for public comment and review

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

On 08/25/2013 02:42 AM, Richard Sandiford wrote:
> Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> > On 08/24/2013 08:05 AM, Richard Sandiford wrote:
> > > Richard Sandiford <rdsandiford@googlemail.com> writes:
> > > > I wonder how easy it would be to restrict this use of "zero precision"
> > > > (i.e. flexible precision) to those where primitive types like "int" are
> > > > used as template arguments to operators, and require a precision when
> > > > constructing a wide_int.  I wouldn't have expected "real" precision 0
> > > > (from zero-width bitfields or whatever) to need any special handling
> > > > compared to precision 1 or 2.
> > > I tried the last bit -- requiring a precision when constructing a
> > > wide_int -- and it seemed surprising easy.  What do you think of
> > > the attached?  Most of the forced knock-on changes seem like improvements,
> > > but the java part is a bit ugly.  I also went with "wide_int (0, prec).cmp"
> > > for now, although I'd like to add static cmp, cmps and cmpu alongside
> > > leu_p, etc., if that's OK.  It would then be possible to write
> > > "wide_int::cmp (0, ...)" and avoid the wide_int construction altogether.
> > >
> > > I wondered whether you might also want to get rid of the build_int_cst*
> > > functions, but that still looks a long way off, so I hope using them in
> > > these two places doesn't seem too bad.
> > >
> > > This is just an incremental step.  I've also only run it through a
> > > subset of the testsuite so far, but full tests are in progress...
> > So i am going to make two high level comments here and then i am going
> > to leave the ultimate decision to the community.   (1) I am mildly in
> > favor of leaving prec 0 stuff the way that it is (2) my guess is that
> > richi also will favor this.   My justification for (2) is because he had
> > a lot of comments about this before he went on leave and this is
> > substantially the way that it was when he left. Also, remember that one
> > of his biggest dislikes was having to specify precisions.
> Hmm, but you seem to be talking about zero precision in general.
> (I'm going to call it "flexible precision" to avoid confusion with
> the zero-width bitfield stuff.)
I have tried to purge the zero width bitfield case from my mind. it was 
an ugly incident in the conversion.


> Whereas this patch is specifically
> about constructing flexible-precision _wide_int_ objects.  I think
> wide_int objects should always have a known, fixed precision.
This is where we differ.  I do not.   The top level idea is really 
motivated by richi, but i have come to appreciate his criticism. Many of 
the times, the specification of the precision is simply redundant and it 
glops up the code.

> Note that fixed_wide_ints can still use primitive types in the
> same way as before, since there the precision is inherent to the
> fixed_wide_int.  The templated operators also work in the same
> way as before.  Only the construction of wide_int proper is affected.
>
> As it stands you have various wide_int operators that cannot handle two
> flexible-precision inputs.  This means that innocent-looking code like:
>
>    extern wide_int foo (wide_int);
>    wide_int bar () { return foo (0); }
>
> ICEs when combined with equally innocent-looking code like:
>
>    wide_int foo (wide_int x) { return x + 1; }
>
> So in practice you have to know when calling a function whether any
> paths in that function will try applying an operator with a primitive type.
> If so, you need to specify a precison when constructing the wide_int
> argument.  If not you can leave it out.  That seems really unclean.
my wife, who is a lawyer, likes to quote an old Brittish chancellor: 
"hard cases make bad law".
The fact that you occasionally  have to specify one should not be 
justification for throwing out the entire thing.

> The point of this template stuff is to avoid constructing wide_int objects
> from primitive integers whereever possible.  And I think the fairly
> small size of the patch shows that you've succeeded in doing that.
> But I think we really should specify a precision in the handful of cases
> where a wide_int does still need to be constructed directly from
> a primitive type.
>
> Thanks,
> Richard
As i said earlier.    Lets see what others in the community feel about this.