On Wed, 14 May 2014, H. Peter Anvin wrote: > On 05/14/2014 02:33 PM, John Stultz wrote: > > > > We can do some tricks for internal optimizations here if these are > > critical. I'd be more concerned about userland divisions where moving > > to a 64bit time_t would cause performance issues that we cannot help > > optimize. > > > > Honestly, the cost of not addressing the Y2038 problem in plenty of time > is going to be way, way, way, way more expensive than some additional > arithmetic. > > As far as converting to calendar notation (e.g. the Gregorian calendar), > only the first division needs to be done with full time_t width. > Furthermore, since the divisor is known a priori, the compiler *should* > be able to do it as an inverse multiply.[1] The compiler is apparently not that smart. It does it already for 32 by 32 bit divisions, but not for 64 by 32 divisions. Fortunately, with gcc-4 at least, constant propagation on long longs works well enough to do it by hand. That's how I implemented do_div() for ARM years ago. See arch/arm/include/asm/div64.h from line 65. The same could be implemented for x86 and others. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
