2.4 kernel & gcc code generation: a bug?

From: Ulrich Windl (Ulrich.Windl@rz.uni-regensburg.de)
Date: Wed Feb 07 2001 - 02:36:22 EST

Trying to find out what got broken in kernel 2.4, I was so clueless as
to compare assembly output for 2.2.18 with 2.4.1. However the assembler
is quite different, as 2.4 uses the more advanced optimizations of gcc-
2.95.2. Anyway:

1) spinlocks look strange in 2.2(!):

.globl rtc_lock
        .type rtc_lock,@object
        .size rtc_lock,0
.globl i8253_lock

while in 2.4.1 they look like this:

.globl rtc_lock
        .align 4
        .type rtc_lock,@object
        .size rtc_lock,4
        .long 0
.globl i8253_lock

2) gcc seems to fail to save registers that are marked "spilled" in
inline asm's constraints, like rdtsc():

/* nanoseconds since last timer interrupt (using the CPU cycle-counter) */
static inline unsigned long do_exact_nanotime(void)
        register unsigned long eax asm("ax");
        register unsigned long edx asm("dx");
        unsigned long result;

        rdtsc(eax, edx); /* Read the Time Stamp Counter

        /* .. relative to previous jiffy (32 bits is enough) */
        eax -= last_tsc_low; /* tsc_low delta */

         * Time offset = (tsc_low delta << 4) * exact_nanotime_quotient
         * = (tsc_low delta << 4) * (nsecs_per_clock)
         * = (tsc_low delta << 4) * (nsecs_per_jiffy /
         * clocks_per_jiffy)
         * Using a mull instead of a divl saves up to 31 clock cycles
         * in the critical path.
        __asm__("mull %2"
                :"=a" (eax), "=d" (edx)
                :"rm" (exact_nanotime_quotient),
                 "0" (eax << 4));

        /* our adjusted time offset in nanoseconds */
        result = nanodelay_at_last_interrupt + edx;
        return result;

        .align 4
.type do_exact_nanotime,@function
subl last_tsc_low,%eax
sall $4,%eax
        mull exact_nanotime_quotient
movl nanodelay_at_last_interrupt,%eax
addl %edx,%eax
.size do_exact_nanotime,.Lfe7-do_exact_nanotime
        .local last_rtc_update
.comm last_rtc_update,4,4
.comm timer_ack,4,4
        .ident "GCC: (GNU) 2.95.2 19991024 (release)"


You'll notice that %edx is not pushed at the start of the function.
Unless the caller saves that, edx will be spilled. Depending on the
level of optimization this can be bad. Am I wrong?

P.S: Not subscribed here, so plese CC: if possible.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Wed Feb 07 2001 - 21:00:26 EST