lkml.org 
[lkml]   [2005]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [BUG mm] "fixed" i386 memcpy inlining buggy
    From
    Date
    Am Mittwoch, den 06.04.2005, 13:14 +0300 schrieb Denis Vlasenko:

    > Oh shit. I was trying to be too clever. I still run with this patch,
    > so it must be happening very rarely.

    Yes, that's right, it happened with code that's not in the mainline tree
    but could have happened anywhere.

    > Does this one compile ok?

    Yes, the case that failed is now okay. I changed it slightly to assign
    esi and edi directy on top of the functions, no asm section needed here.
    The compiler will make sure that they have the correct values when
    needed.

    In the case above the compiler now uses %ebx to save the loop counter
    instead of %esi.

    In drivers/cdrom/cdrom.c I'm observing one very strange thing though.

    It appears that the compiler decided to put the local variable edi on
    the stack for some unexplicable reason (or possibly there is?). Since
    the asm sections are memory barriers the compiler then saves the value
    of %edi on the stack before entering the next assembler section.

    1f1c: a5 movsl %ds:(%esi),%es:(%edi)
    1f1d: 89 7d 84 mov %edi,0xffffff84(%ebp)
    1f20: a5 movsl %ds:(%esi),%es:(%edi)
    1f21: 89 7d 84 mov %edi,0xffffff84(%ebp)
    1f24: 66 a5 movsw %ds:(%esi),%es:(%edi)

    (this is a constant 10 byte memcpy)

    The only thing that would avoid this is to either tell the compiler to
    never put esi/edi in memory (which I think is not possibly across
    different versions of gcc) or to always generate a single asm section
    for all the different cases.

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-04-06 14:16    [W:4.212 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site