[FFmpeg-devel] [PATCH] ff_scalarproduct_float_sse

[Michael Kostylev]

On Wed Jan 20 22:29:43 2010
M?ns Rullg?rd wrote:

> Michael Niedermayer <michaelni at gmx.at> writes:
> 
>> On Wed, Jan 20, 2010 at 09:31:14PM +0000, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>> 
>>>> On Wed, Jan 20, 2010 at 02:48:57PM +0000, M?ns Rullg?rd wrote:
>>>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>>> 
>>>>>> 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 have to disagree.  Just look at how many FATE targets broke with
>>>>> your change to h264_loop_filter_strength_mmx2 yesterday.  Several
>>>>> compilers are still failing to build it.
>>>>
>>>> what we had is called a syntax error, yasm wont do any better
>>>> if you make such errors, though yasm would more consistently fail i guess
>>> 
>>> There was no syntax error.  A syntax error would have had gcc say
>>> "syntax error", which it didn't.  In fact, it compiled just fine on
>>> x86_64, only failing mysteriously on x86_32.  David then fixed it with
>>> gcc, leaving only icc and suncc failing.
>>
>> 8+1*(%blah) is a syntax error
>> so is
>> 8+(%blah)
>> some versions of gas support it and depending on luck you might end
>> with 8+1*%m being substututed to 8+1*123(%blah) which isnt a syntax
>> error still davids code was not correct this has nothing to do with gcc
>> inline asm.
> 
> I was talking about your original commit.  It didn't have any such
> syntax and still broke on _every_ x86_32 compiler.

To be more precise, gcc on DragonFly wasn't affected at all, suncc complained
only about the above "syntax error".

Michael