Intel C Compiler

From MultimediaWiki
(Redirected from Icc)
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:

11.1

11.1.059 is currently covered by FATE.

11.1 32 bit

11.1.038 (and later) are supported and expected to pass regression tests.

fate-atrac3-1 fails if libavcodec/atrac3.c is compiled with optimisations > O1 (channelWeighting() is miscompiled). This is Intel issue 606524 (will not be fixed). A possible work-around is to force the compiler not to inline getChannelWeights().

11.1 64 bit

11.1.058 (and later) are supported and expected to pass regression tests.

fate-sipr-5k0, fate-sipr-6k5 and fate-sipr-8k5 fail if libavcodec/sipr.c is compiled with optimisation > O2 (Intel issue 608891, will not be fixed).

All versions including 11.1.072 (fixed in 11.1.073) miscompile the function decode_var_block_data() in libavcodec/alsdec.c (Intel issue 583664), possible work-arounds are:

  • Pass -parallel to the compilation
  • Don't compile alsdec.c with -O3
  • Disable optimizations for decode_var_block_data() with #pragma optimize

11.1.069 and earlier badly compiled vc1_mc_4mv_chroma() in libavcodec/vc1dec.c (Intel issue 556938). This was fixed in 11.1.072.

At least 11.1.038 and earlier versions were known to badly compile the following files if optimization is used (Intel issue 540759):

  • libavcodec/h263.c
The function h263_pred_motion() gets miscompiled.
  • 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
The function pred_mv() gets miscompiled.
  • libavcodec/h264.c
The function pred_motion() gets miscompiled.

Possible workarounds are to compile these files with -O0, with icc 10.1 or gcc, or put 

#pragma optimize ( "", off )

and 

#pragma optimize ( "", on )

around the affected functions. 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.

IA64

The MP2 and the AC3 encoder are miscompiled (crash on encoding), This is Intel issue 612292, unlikely to get fixed ("Intel IA64 is not designed for A/V appliction").

Response from the engineering team: 

1. Without inlining the function getChannelWeights as follows, we can get correct result with -O2 or higher opt level.
static void __attribute__((noinline)) getChannelWeights (int indx, int flag, float ch[2])

2.It might be fine to get rid of the store to w[], since w[] is a local array, and its values are stored in registers, which is t154 in this case:

628 BB3 64 if ( t149_694 == 7(SI32) )
{
628 BB6 782 t257_782 = 1.00000000e+00=0x3f800000(F32);
628 BB6 78 t154_78 = t257_782;
628 BB6 698 *((F32*) &w.1518_V$2a1.0.28) = t257_782;
628 BB6 79 t156_79 = t257_782;
628 BB6 703 *((F32*) ((4(SI64) + &w.1518_V$2a1.0.28))) = t257_782;
} else {

11.0

11.0.083 is currently covered by FATE.

11.0 32 bit

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

11.0.083 is covered by FATE.

fate-atrac3-1 fails if libavcodec/atrac3.c is compiled with optimisations > O1.

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.038 exist for all versions, at least including 11.0.084 (Intel issue 540759). This is very unlikely to get fixed.

All versions are known to incorrectly compile vc1_mc_4mv_chroma() in libavcodec/vc1dec.c leading to artefacts when decoding some files (Intel issue 556938). A possible workaround is to compile vc1dec.c with -O0.

10.1

10.1.022 is covered by FATE.

10.1 32 bit

Compiling libavcodec/vorbis_dec.o fails with an internal error since the change to SHOW_UBITS in r21948 if "-parallel" was passed to the compiler. This is Intel issue 583182 and unlikely to get fixed.

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

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

To pass the regression tests, the cpu option has to be passed to configure: --cpu=pentium3|pentium4|core2.

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.

The function vc1_mc_4mv_chroma() in libavcodec/vc1dec.c is miscompiled, leading to artefacts (for example with the sample from issue 255). This is unlikely to get fixed for 10.1. Possible workarounds are to disable optimization for this function using pragma optimize or compile vc1dec.c with -O0.

12.0 Beta

12.0.0 Beta 025 has the following problems:

  • ICE on attribute alloc_size
  • attribute may_alias not supported (not relevant since FFmpeg does not pass -ansi-alias to the compiler)
  • attribute force_align_arg_pointer not supported

The following problems with older compiler versions were fixed:

  • attribute used finally works as expected, making the special case for DECLARE_ASM_CONST unneeded
  • stack pointer alignment for x86-32 works as in gcc, allowing to use mentioned x264 functions
  • als decoding fixed

12.0.1 Beta 048 fails for the following regression tests:

  • libavformat/mov.c is miscompiled since r23764 (crash on reading alac.m4a) - Intel issue 602884
  • libavcodec/gifdec.c is miscompiled for -O2 and higher: lavf.gif cannot be decoded (gif_parse_next_image() in libavcodec/gifdec.c) - Intel issue 602887

MPlayer

The only additional issue MPlayer has is that it used to be difficult to compile a 32 bit binary with icc on a 64 bit system, but this was fixed in MPlayer's configure script.

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.
Retrieved from "https://wiki.multimedia.cx/index.php?title=Intel_C_Compiler&oldid=13326"