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

[Matt Oliver]

On 5 January 2014 13:27, Matt Oliver <protogonoi at gmail.com> wrote:

> On 30 December 2013 13:06, Matt Oliver <protogonoi at gmail.com> wrote:
>
>> On 30 December 2013 02:26, Michael Niedermayer <michaelni at gmx.at> wrote:
>>
>>> On Sun, Dec 29, 2013 at 02:19:40PM +0100, Reimar Döffinger wrote:
>>> > On Sun, Dec 29, 2013 at 02:48:52PM +1100, Matt Oliver wrote:
>>> > > is to much to ask. The only other option I can think of is to have
>>> > > different versions. i.e. for those few lines with direct symbol
>>> references
>>> > > have an #ifdef that only changes the code for Intel compiler on
>>> Windows.
>>> > > Windows shared libraries dont need PIC so this shouldn't be a
>>> problem.
>>> > > Although the code may become a bit ugly.
>>> >
>>> > One thing I thought of: You could try using named asm constraints, and
>>> > only change the MANGLE to convert to a reference to a named asm
>>> > argument.
>>> > If you are lucky in quite a few cases you'd then only need an ifdef
>>> > around the extra asm constraints.
>>>
>>> that should be possible without ifdef, see XMM_CLOBBERS_ONLY() for
>>> something similar
>>>
>>> [...]
>>> --
>>> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> You can kill me, but you cannot change the truth.
>>>
>>
>> Using named asm constraints is a good idea as it seems that Intel
>> compiler supports those. So I will update the patch so that MANGLE remains
>> in use but it will just change to a named asm constraint on Intel+Windows.
>> Combine that with a macro such as XMM_CLOBBERS_ONLY in order to add the
>> necessary asm interfaces and that should work fine.
>>
>> That one thing I did notice though is that if the use of "m" constraints
>> with PIC is an issue then there are several locations in existing code that
>> dont seem to follow that. For instance in libavcodec/x86/cavsdsp.c the
>> macro QPEL_CAVSV1 uses a asm interface for MUL1 (which is variable ff_pw_96
>> and is assigned to %5). However MUL2 (which is variable ff_pw_42) is used
>> as a direct symbol through MANGLE. Since both these variables are defined
>> in the same place and are of the same type (uint64_t) then it appears there
>> are some inconsistencies in existing FFmpeg code. Ill leave all existing
>> instances of MANGLE but i thought id just point this out.
>>
>
> OK so I have redone the patch using named asm constraints and a macro to
> add them to the asm-interface (similar to XMM_CLOBBERS_ONLY as discussed).
>
> There are only 2 locations that are slightly different and these are in
> motion_est.c and vf_fspp.c. The inline asm in Intel compiler is rather
> unstable and changing some compilation flags suddenly result in errors from
> what was previously perfectly functional asm. To get compilation to work
> using standard release options 2 variables were changed from direct symbol
> references to an asm-interface. This should not be a problem as these
> symbols are defined in asm-interfaces already (for instance in vf_fspp.c
> temps[0] is already in an interface and all I did was add temps[1]). So the
> patch does not change anything that didnt already exist.
>
> To ensure everything stayed the same I compiled using gcc 4.8.2 and
> checked the generated disassembly for the part affected. For all changes
> the resulting code is exactly identical so this does not change anything
> (which for the most part it shouldn't anyway as the macros only change when
> using Intel on Windows). So no surprises there but I thought i would be
> thorough just to be sure. So obviously all FATE tests passed.
>
> Let me know how this one looks.
>

A minor addition to the last patch. There was a file I missed as it is only
enabled when fast_cmov is active. The Intel compiler has a whole lot of
bugs on this one as it will compile in 32bit but not 64bit. So for the
moment it is just disabled for 64bit intel compiler on windows.

So this should be everything and using default release compile options with
the changes in the patch it is now possible to build with inline asm
enabled with the Intel compiler on windows.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fixed-inline-asm-compilation-with-Intel-compiler.patch
Type: application/octet-stream
Size: 52182 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140125/a1f6079f/attachment.obj>