On Wed, Nov 24, 2010 at 02:48:01PM +0000, Pedro Alves wrote: > On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote: > > Quoting Pedro Alves <pe...@codesourcery.com>: > > Also, these separate hooks for common operations can make the code more > > readable, particularly in the bits_in_units_ceil case. > > I.e. > > foo_var = ((bitsize + targetm.bits_per_unit () - 1) > > / targetm.bits_per_unit ()); > > vs. > > foo_var = targetm.bits_in_units_ceil (bitsize); > > > > bits_in_units_ceil could well be a macro or helper function > implemented on top of targetm.bits_per_unit (which itself could > be a data field instead of a function call), that only accessed > bits_per_unit once. It could even be implemented as a helper > macro / function today, on top of BITS_PER_UNIT.
I think adding the functions as inline functions somewhere and using them in the appropriate places would be a reasonable standalone cleanup. It'd be easy to move towards something more general later. Writing: int bits = ...; ... (X + bits - 1)/ bits; also generates ever-so-slightly smaller code than: ... (X + BITS_PER_UNIT - 1) / BITS_PER_UNIT; on targets where BITS_PER_UNIT is not constant. I personally am not a fan of the X_in_Y naming, though; I think X_to_Y is a little clearer. -Nathan
