2001-02-07 07:36:58

by Ulrich Windl

[permalink] [raw]
Subject: 2.4 kernel & gcc code generation: a bug?

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
rtc_lock:
.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
rtc_lock:
.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;
}

.text
.align 4
.type do_exact_nanotime,@function
do_exact_nanotime:
#APP
rdtsc
#NO_APP
subl last_tsc_low,%eax
sall $4,%eax
#APP
mull exact_nanotime_quotient
#NO_APP
movl nanodelay_at_last_interrupt,%eax
addl %edx,%eax
ret
.Lfe7:
.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)"

#endif


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?

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


2001-02-07 07:47:21

by H. Peter Anvin

[permalink] [raw]
Subject: Re: 2.4 kernel & gcc code generation: a bug?

Followup to: <3A8108F8.2476.21D0F5@localhost>
By author: "Ulrich Windl" <[email protected]>
In newsgroup: linux.dev.kernel
>
> 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?
>

Yes. %eax, %edx and %ecx are defined as caller-saved registers. Each
function is free to clobber them at will.

Now, if you saw the same for %ebx, %ebp, %esi or %edi, that would be
bad.

-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt