[MPlayer-dev-eng] [PATCH] x86_64 mmx/sse/3dnow optimisation support

[D Richard Felker III]

On Sun, Oct 17, 2004 at 04:41:28PM +0200, Aurelien Jacobs wrote:
> > just don't tell pullup that mmx/etc is supported if you're on x86-64
> > and maybe sometime i'll come up with a better solution. (note that
> > pullup.c did not already include cpudetect.h, for good reason!)
> 
> Ok.
> I see 2 solutions :
>  - I could replace the inclue of cpudetect.h by defines of REG_a, etc..
>    which would still keep mmx supported on x86_64 without mplayer
>    dependencie.
>  - Else, I'll need to replace the #ifdef HAVE_MMX by a 
>    #if defined(HAVE_MXX) && !defined(ARCH_X86_64)
> 
> Which one do you prefer ? (I guess the second, but keeping x86_64 mmx
> support may be nice)

approximately the second. but put a separate #ifndef ARCH_X86_64 (or
preferably #ifdef ARCH_X86, if it's not defined for x86-64) on the
outside around the other #ifdef, since it's possible i'll add 3dnow or
other optimized functions later.

> > otherwise, i see lots of unnecessary changes from int->long in vf_*.c.
> > please comment on why their necessary. i agree x86-64 support is
> > useful, but i don't like excessive cosmetic patches especially when
> > they reduce readability excessively like this.
> 
> I don't like cosmetic too !
> If I added so much int->long that's because they were needed.
> 
> Here is an exemple :
> 	    "movq (%0,%2,2), %%mm1\n\t"
> ....
> -	    : "r"(as), "r"(bs), "m" (ones), "0"(a), "1"(b), "X"(*a), "X"(*b) \
> +	    : "r"((long)as), "r"((long)bs), "m" (ones), "0"(a), "1"(b), "X"(*a),
> 
> Here, %0 is used for addressing, so it need to be a 64 bits register.
> as and bs are ints, so they will expand to 32 bits register and this
> will prevent compilation.

casting to long like this is fine. but there were lots of local
variables where you changed the types. there were also functions where
you changed the types of function arguments which i find really bad.
the types were chosen to be the types that are logical from a _caller_
standpoint, not for the internal optimizations of the called function.

rich