[FFmpeg-devel] [PATCH] ff_scalarproduct_float_sse

[Måns Rullgård]

Jason Garrett-Glaser <darkshikari at gmail.com> writes:

> On Wed, Jan 20, 2010 at 12:58 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>> On Wed, Jan 20, 2010 at 03:43:23PM -0500, David Conrad wrote:
>>> On Jan 20, 2010, at 9:19 AM, Michael Niedermayer wrote:
>>>
>>> > On Tue, Jan 19, 2010 at 11:42:40PM -0500, Alex Converse wrote:
>>> >> This cause a >50% decrease in SBR decode time.
>>> >>
>>> >> For the time being it can help in the other places where
>>> >> scalarproduct_float() is used.
>>> >>
>>> >> Regards,
>>> >> Alex Converse
>>> >
>>> >> dsputil_mmx.c ? ?| ? ?5 +++++
>>> >> dsputil_yasm.asm | ? 25 +++++++++++++++++++++++++
>>> >
>>> > Would you mind to avoid yasm and use gcc asm instead ?
>>> >
>>> > I have no problem with yasm as such but gcc asm is more portable and
>>> > can be integrated with C code if we ever want that.
>>>
>>> I'd argue that it's less portable given that the majority of the
>>> compiler bugs I've encountered stem from inline asm. In fact,
>>> right now llvm svn trips on two separate inline asm bugs on
>>> x86-32, and llvm-gcc on another on x86-64. And gcc-4.2 and later
>>> have several silent miscompilations and register allocation
>>> failure with inline asm on x86-32 OS X when using PIC.
>>
>> Less maintenance effort probably, but not more portable by my
>> definition of it.  Last time we discussed it at least it didn't
>> work e.g. on OS/2.  And it's always something that doesn't come
>> with the system. I just realized I've been doing my last Windows
>> builds of FFmpeg and MPlayer without yasm because I forgot to
>> install it...
>
> "Doesn't work on OS/2" is better than "doesn't work on 2/3 of targets
> because GCC doesn't like the phase of the moon".

Full ack.

It's worse than that too.  While inline asm breaks randomly with gcc
version changes, yasm support is stable.

-- 
M?ns Rullg?rd
mans at mansr.com