I ran a quick profile with this patch and it eliminated a couple of divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your mileage may vary) which was good for 493 instructions. Still have 3 __divu64 and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() CRT function, so there is not much we can do about these directly. One __divi64 is in apr_poll (convert microseconds to milliseconds. This can probably be optimized away). The other __divi64 is somewhere in cached_explode (util_time.c).
Bill > At 10:38 PM 7/10/2002, William A. Rowe, Jr. wrote: > >At 10:03 PM 7/10/2002, Brian Pane wrote: > >>Bill Stoddard wrote: > >> > >>>I've not looked at the generated code, but profiling indicates that an > >>>additional division is happening, adding an extra 231 instructions. > >>>(xlc_r -O2) > >> > >>If you redefine the macro as a shift, does the profile look better? > > Ok, attached is the code redone as binary math. I'm tired, could be > any number of major blunders in it, but on first pass, it looked right. > > Bill