[FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Ronald S. Bultje]

Hi,

On Mon, Oct 24, 2016 at 3:34 PM, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 24 Oct 2016 21:19:46 +0200
> Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>
> > On 24.10.2016 16:14, Ronald S. Bultje wrote:
> > > On Mon, Oct 24, 2016 at 8:47 AM, wm4 <nfxjfg at googlemail.com> wrote:
> > >> On Mon, 24 Oct 2016 07:54:47 -0400
> > >> "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> > >>> On Mon, Oct 24, 2016 at 3:36 AM, wm4 <nfxjfg at googlemail.com> wrote:
> > >>>> I was under the impression that it is UB to have the FPU in MMX
> state
> > >>>> at any time while in C, not just while e.g. calling the stdlib.
> Maybe I
> > >>>> got that wrong (how would MMX intrinsics even work?) - can anyone
> shed
> > >>>> light on the exact requirements? (Possibly again, sorry.)
> > >>>
> > >>> I'm under the impression that it's part of the calling convention.
> That
> > >> is,
> > >>> any code anywhere (including mmx intrinsics, indeed) can - when
> called -
> > >>> expect the state to be cleared by the caller, just like you'd expect
> > >>> eax/edx to be caller-save (whereas esi/edi are callee-save).
> > >>>
> > >>> However, if you never call external code (including intrinsics), you
> can
> > >>> ignore this, just as you can ignore / create your own calling
> > >>> convention (remember fastcall etc.?). However, when calling any
> external
> > >>> code, this could (in theory) crash; it's just that right now it only
> > >>> crashes with musl when calling malloc/free. So basically, ffmpeg has
> its
> > >>> own calling convention, and manually calling emms_c() fixes "ffmpeg"
> > >>> calling convention to be compatible with "standard" calling
> > >> convention...?
> > >>
> > >> It can't really be a calling convention unless the compiler is aware
> of
> > >> it?
> >
> > It is defined as part of the System V Application Binary Interface [1]:
> > "The CPU shall be in x87 mode upon entry to a function. Therefore, every
> > function that uses the MMX registers is required to issue an emms or
> femms
> > instruction after using MMX registers, before returning or calling
> another
> > function."
>
> I mean FFmpeg can't make up its own calling convention without the
> compiler's knowledge.
>
> But thanks for reminding me about this but of the sysv ABI. The
> paragraph you quoted is actually very clear about the requirements. It
> means FFmpeg can barely do anything and remain standard compliant: a
> ASM function must, according to the calling convention, reset the MMX
> state when returning.
>
> What FFmpeg does here was misdesigned from the very start.


Good idea to reference Hendrik Gramner here, who keeps insisting we get rid
of all MMX code in ffmpeg (at least as an option) for future Intel CPUs in
which MMX will be deprecated.

Food for thought, indeed.

Ronald