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

[Matt Oliver]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fixed-inline-asm-compilation-with-Intel-compiler.patch
Type: application/octet-stream
Size: 51601 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140105/9c376fa2/attachment.obj>