On 9/5/12, Richard Guenther <[email protected]> wrote:
> On Tue, 4 Sep 2012, Lawrence Crowl wrote:
>> Modify gcc/*.[hc] double_int call sites to use the new interface.
>> This change entailed adding a few new methods to double_int.
>>
>> Other changes will happen in separate patches. Once all uses of
>> the old interface are gone, they will be removed.
>>
>> The change results in a 0.163% time improvement with a 70%
>> confidence.
>>
>> Tested on x86_64.
>> Index: gcc/ChangeLog
>
> - double_int_lshift
> - (double_int_one,
> - TREE_INT_CST_LOW (vr1.min),
> - TYPE_PRECISION (expr_type),
> - false));
> + double_int_one
> + .llshift (TREE_INT_CST_LOW
> (vr1.min),
> + TYPE_PRECISION
> (expr_type)));
>
> Ick - is that what our coding-conventions say? I mean the
> .llshift on the next line.
Our conventions say nothing about that, but method calls seem
somewhat analogoust to binary operators, and hence this formatting
was probably the least objectional.
> Otherwise ok.
As in you want me to do something else?
> The tmin.cmp (tmax, uns) > 0 kind of things look odd - definitely
> methods like tmin.gt (tmax, uns) would be nice to have. Or even
> better, get rid of the 'uns' parameters and provide a
>
> struct double_int_with_signedness {
> double_int val;
> bool uns;
> };
>
> struct double_uint : double_int_with_signedness {
> double_uint (double_int);
> };
>
> ...
>
> and comparison operators which take double_uint/sint.
It would, I think, be better to have separate signed and unsigned
types. That change was significantly structural, and I don't know
where the wide_int work sits in relation to that choice.
> You didn't remove any of the old interfaces, so I think we are
> going to bitrot quickly again.
I couldn't remove the old interface yet because I haven't updated
all the code yet.
--
Lawrence Crowl
