Intel C Compiler

From MultimediaWiki
Revision as of 13:49, 16 April 2009 by Angustia (talk | contribs) (Create a topic just for the Windows version and add some more content.)
Jump to navigation Jump to search

Intel sells a C++ compiler for Windows, Linux and OS X that is freely available for non-commercial usage. The Linux version of the compiler can be used to compile binaries of MPlayer and FFmpeg that are known to be slightly more optimized speed-wise than binaries compiled with gcc. The Windows version still has some issues.

Caveats

For 32 bit compilation with icc, the following highly optimized SSE2 functions for H264 decoding cannot be used due to stack pointer alignment issues. The functions are deactivated for non-beta versions of icc.

  • ff_x264_deblock_v_luma_sse2
  • ff_x264_deblock_h_luma_sse2
  • ff_x264_deblock_v_luma_intra_sse2
  • ff_x264_deblock_h_luma_intra_sse2

A possible fix would be to define a prologue and epilogue for these functions in libavcodec/x86/x86inc.asm that saves, aligns and restores the stack pointer.

FFmpeg

Compilation with icc was tested for the following versions:

10.1

10.1 32 bit

Versions prior to 10.1.021 cannot compile the program audiogen, needed for regression tests. A possible workaround is using gcc to compile audiogen:

./configure --cc=icc --host-cc=gcc

10.1.017 is covered by FATE.

10.1 64 bit

All versions should be supported and are expected to pass regression tests. Note that the iccbin binary itself is a 32 bit executable, seemingly causing trouble on some installations (such as the server running FATE tests for x86_64 / Linux).

At least icc 10.1.021 is known to incorrectly compile libavcodec/vc1.c leading to artefacts when compiling some files. A possible workaround is to compile vc1.c with -O0.

11.0

11.0 32 bit

All versions should be supported and are expected to pass regression tests.

11.0 64 bit

11.0.081 and prior versions are known to fail compiling dsputil_mmx.c and cavsdsp_mmx.c with an internal error. This was fixed with 11.0.083.

The same issues as with 11.1.023 exist for all versions (at least including 11.0.083).

At least icc 11.1.083 is known to incorrectly compile libavcodec/vc1.c leading to artefacts when compiling some files. A possible workaround is to compile vc1.c with -O0.

11.1 Beta

11.1 32 bit

If compilation of said sse2 functions is disabled (which will be done if 11.1 is released), 11.1.023 will be supported and is expected to pass regression tests.

11.1 64 bit

At least 11.1.023 is known to badly compile the following files if optimization is used:

  • libavcodec/h263.c
  • libavcodec/wmv2dec.c
The functon wmv2_pred_motion() gets miscompiled: A printf() after the initialization of *C shows that mot_val, A[], B[] and C[] often differ from compilation with -O0 while xy and wrap are unchanged.
Artefacts are clearly visible.
  • libavcodec/snow.c
  • libavcodec/h264.c

Possible workarounds are to compile these files with -O0, with icc 10.1 or gcc. With one of these workarounds, regression tests are expected to pass. Earlier beta versions were not able to compile FFmpeg with optimizations enabled: Compilation of dsputil_mmx.c and cavsdsp_mmx.c failed.

MPlayer

The only additional issue MPlayer has is that it is difficult to compile a 32 bit binary with icc on a 64 bit system because MPlayer's configure script does not test what kind of object file the compiler outputs (and icc does not know the option -m32, but has different binaries for 32 and 64 bit).

Windows version

The Windows version of the compiler cannot be used to compile FFmpeg. The main issues are:

  • it uses Microsoft's header files and libs, which are not POSIX compliant;
  • it does not support ".align" in assembly;
  • it does not accept constructs such as
int foo = ({int bar=10; bar;});

which are used by macros in FFmpeg;

  • it does not support the MANGLE macro. This gives error messages such as:
error: The direct symbol reference in movq is currently unsupported.  Access symbols through the asm interface.

Some positive points that make it much more attractive than Microsoft Visual C++ for a port effort are:

  • it supports C99;
  • it accepts at&t style asm.