Re: [BUG mm] "fixed" i386 memcpy inlining buggy

[Christophe Saout <christophe@saout.de>]

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.

Attachment: signature.asc
Description: This is a digitally signed message part