On 9/5/12, Richard Guenther <rguent...@suse.de> 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