On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote: > Quoting Pedro Alves <pe...@codesourcery.com>: > > > On Tuesday 23 November 2010 20:09:52, Joern Rennecke wrote: > >> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this > >> would not only cost a data load from the target vector, but would also > >> inhibit optimizations that replace division / modulo / multiply with shift > >> or mask operations. > > > > Have you done any sort of measurement, to see if what is lost > > is actually noticeable in practice? > > No, I haven't. > On an i686 it's probably not measurable. On a host with a slow software > divide it might be, if the code paths that require these operations are > exercised a lot - that would also depend on the source code being compiled.
And I imagine that it should be possible to factor out many of the slow divides out of hot loops, if the compiler doesn't manage to do that already. > 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. Making design decisions like this based on supposedly missed optimizations _alone_, without knowing how much overhead we're talking about is really the wrong way to do things. -- Pedro Alves
