[Mplayer-dev-eng] [LONG] gcc-3.0.x: problems with mmx & ffdivx + patch

[Nick Kurshev]

Hi, pl!

On 2001-07-24 18:58:52 you wrote:

>Well... Since I don't have a C bible available I can't say who's
>wrong/right but here is what I found.
>
>gcc-3.0 does not produce the code expected at optimization level -Ox (x>=1)
>for main/libavcodec/i386/mpegvideo.c with MMX enabled.
>
>The problem comes from the use of the const attribute for the two data arrays
>(mm_wabs[], mm_wone[]).
>
>As far as I can tell, expected code (first part of Nick's inline asm) is:
>
>[...]
>        movd    %edi, %mm6
>        punpckldq %mm6, %mm6
>        movq    mm_wabs, %mm4		*
>        movq    %mm6, %mm7
>        movq    mm_wone, %mm5		*
>        packssdw %mm6, %mm7
>        pxor    %mm6, %mm6
>[...]
>which effectively corresponds to what is expected load register %mm? with the
>8 bytes of mm_w???[].
>
>gcc-3.0 at -O4 generate the following "evil" code:
>[...]
>.LC113:
>        .value  1
>        .align 2
>.LC114:
>        .value  65535
>        .text
>        .align 16
>[...]
>        movd    %edi, %mm6
>        punpckldq %mm6, %mm6
>        movq    .LC114, %mm4		*	
>        movq    %mm6, %mm7
>        movq    .LC113, %mm5		*
>        packssdw %mm6, %mm7
>        pxor    %mm6, %mm6
>[...]
>
>And there it does not load completely what it should...
>Therefore, it sucks.
>The image is completely garbled, women yell, children cry, ...
>
>
>So... as I don't know how the C standard defines the behavior of 
>constant arrays VS inlined asm, here are possible fixes:
>
>Fixes:
>------
> - wait for gcc team to fix it
>
> - explicitely not use gcc-3.0.x for this file
>
> - use -O0 for this file
>
> - remove the const attribute for:
>     static const unsigned short mm_wabs[4] __attribute__ ...
>     static const unsigned short mm_wone[4] __attribute__ ...
>
> - change unsigned short[4] to unsigned long long
>   (see patch enclosed) (preferred and maybe cleaner)
>
Your gcc is sucks!!! The constructions which you use in patch
are common for this file. If you look at several lines below of
the block which you've patched you'll find there the same code
which don't caused any problem on your gcc. Therefore it's
problem of gcc. could you tell me please - what type of "C"
you will use for 16-bit SSE? So it's not solution (maybe partial for your
situation but in general it doesn't remove a problem - only hides it).

Do you report about this problem to gcc team? They planned to release 3.0.1 soon.
I didn't understand what version of gcc you use - official 3.0 or 3.0.1-pre
but imho it's gcc's bug and it would be better to fix it in compiler.

Best regards! Nick (2001-07-24 22:15:58)


_______________________________________________
Mplayer-dev-eng mailing list
Mplayer-dev-eng at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng