Forwarding this to linux-arch mostly as a heads up to other arch
maintainers
and discussion. With gcc's optimizer getting increasingly smarter
I'm not
so sure if below patch is the right thing. In timespec_add_ns we
would
normally except the loop to be interated once at most and gcc should
make
this assumption due to the unlikely() hint. Anyway, we have to be
prepared for more such code transformations to happen so adding a
__udivdi3
implementation is probably the defensive approach.
I would rather not have it there and therefore know when such
an expensive operation is being emitted by gcc.
It looks like the divide costs might be set wrong on MIPS
in gcc if it thinks udivdi3 is cheaper than this loop.
More likely GCC doesn't know how many times this
loop would run on average, making the loop very
expensive indeed. Perhaps the loop->div optimisation
just doesn't see the "unlikely()". How about filing
a bug report? The original mail says this only
happens with SVN versions of GCC, so if it is handled
fast enough you won't have to deal with this in the
kernel at all.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
