[FFmpeg-devel] Patch: Inline asm fixes for Intel compiler on Windows

Michael Niedermayer michaelni at gmx.at
Sat Dec 28 14:28:04 CET 2013


On Sat, Dec 28, 2013 at 11:35:31AM +1100, Matt Oliver wrote:
> Hey,
> I made a patch that changes some of the inline asm found in FFmpeg so that
> it will compile under windows natively using the Intel compiler. The Intel
> compiler supports AT&T inline assembly syntax but doesnt have all the
> functionality that GAS has. A result is that a few things need to be
> slightly tweaked. Mostly this just involves changing direct symbol
> references to asm-interfaces.
> 
> The attached patch should not change the functionality of FFmpeg in any way
> as it just changes the syntax of some instructions so that it will compile.
> 
> That said there are a few sections where the code required slightly more
> complicated changes in order to work. These are x86/cabac.h in the
> BRANCHLESS_GET_CABAC macro and mlpdsp.c. The macro in cabac.h just requires
> some slightly more complicated asm-interface conversions that someone more
> familiar with the code may want to have a look at. mlpdsp.c uses some
> runtime jump lists that would require an almost complete rewrite to work on
> Intel which is probably not worth it. So at the moment both of these are
> simply skipped if the Intel compile is detected. All other asm works fine
> though.
> 
> Code was compiled on Windows in Intel and using gcc 4.8 to ensure
> compatibility. All code was tested and past FATE.

The patch doesnt apply:

Applying: Patch: Inline asm fixes for Intel compiler on Windows
Using index info to reconstruct a base tree...
error: patch failed: libavcodec/x86/mpegvideoenc_template.c:168
error: libavcodec/x86/mpegvideoenc_template.c: patch does not apply
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.


trying to apply the patch with "patch" does not result in code that
can be compiled.
In file included from /home/michael/ffmpeg-git/ffmpeg/libswscale/x86/yuv2rgb.c:57:0:
/home/michael/ffmpeg-git/ffmpeg/libswscale/x86/yuv2rgb_template.c:333:9: error: memory input 7 is not directly addressable
/home/michael/ffmpeg-git/ffmpeg/libswscale/x86/yuv2rgb_template.c:333:9: error: memory input 8 is not directly addressable
/home/michael/ffmpeg-git/ffmpeg/libswscale/x86/yuv2rgb_template.c:333:9: error: memory input 9 is not directly addressable
/home/michael/ffmpeg-git/ffmpeg/libswscale/x86/yuv2rgb_template.c:333:9: error: memory input 10 is not directly addressable
/home/michael/ffmpeg-git/ffmpeg/libswscale/x86/yuv2rgb_template.c:333:9: error: memory input 11 is not directly addressable


about the changes themselfs, its unlikely that adding operands
to asm will work. These will break some versions of gcc and clang
on x86-32 (and i would not be surprised if they break intels
compiler the same way)

If you want to add operands anyway, then you have to convince us
that its safe on all supported compilers with all common use cases
(position independant code, and various optimization levels for
 example)
(testing with 2-3 old compilers from the 2.95 /3.* era might do, but
 its still alot of work so if theres an alternative to adding operands
 that would likely be easier)

also successfull compilation alone isnt enough, old gcc versions are
known to silently miscompile code that has more than 9 or 10
(and "+" operands counts as 2) operands to an asm
like in the case below

also, if you add operands, the code needs to be benchmarked or the
generated asm compared, gcc (especially at lower optimization levels
and with position independant code has the tendency to add extra code)
for benchmarking START/STOP_TIMER could be used
So i would suggest that a differnt solution is used than adding
operands, if possible


>      : "+r"(block)
> -    :
> +    : "m"(*m127), "m"(*iTab1), "m"(*walkenIdctRounders), "m"(*iTab2), "m"(*iTab3), "m"(*iTab4),
> +      "m"(*tan3), "m"(*tan1), "m"(*tan2), "m"(*sqrt2)
>      : XMM_CLOBBERS("%xmm0" , "%xmm1" , "%xmm2" , "%xmm3" ,
>                     "%xmm4" , "%xmm5" , "%xmm6" , "%xmm7" ,)


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131228/3ffb387e/attachment.asc>


More information about the ffmpeg-devel mailing list