------- Comment #34 from jakub at gcc dot gnu dot org 2007-11-27 19:43 -------
I certainly agree with Mark here, we can talk whether on a particular arch
with particular options this transformation is a win or not, but when the
kernel
people decide to implement libgcc on their own and intentionally leave parts of
it out, they need to handle the consequences of that.
The addition of asm ("" : "+r" (nsec)); to the loop I suggested, perhaps hidden
in some macro, will act as an optimization barrier against it and won't (unlike
volatile) cost anything.
Even when the current scev-cprop transformation might not be a win in the case
of
__builtin_expect unlikely loop, the compiler e.g. could decide to transform
this into:
if (__builtin_expect (nsec < NSEC_PER_SEC, 1))
sec += nsec / NSEC_PER_SEC, nsec %= NSEC_PER_SEC;
or e.g.
if (__builtin_expect (nsec < NSEC_PER_SEC * 10, 1))
while (__builtin_expect (nsec > NSEC_PER_SEC, 0))
nsec -= NSEC_PER_SEC, sec++;
else
sec += nsec / NSEC_PER_SEC, nsec %= NSEC_PER_SEC;
which would still reference __udivdi3, but wouldn't be (measurably) slower in
case nsec is really small, yet would be much faster if nsec happens to be big.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
