[FFmpeg-devel] [PATCH] ff_scalarproduct_float_sse

Michael Niedermayer michaelni
Wed Jan 20 23:38:27 CET 2010


On Wed, Jan 20, 2010 at 10:29:43PM +0000, 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.

yes, it failed and i fixed it
i didnt test on x86_32 and i could have broken yasm as well on x86_32
had i used it and not tested it


> 
> > break the rules for yasm and it fails as well
> > that said its gas not gcc for which it is a syntax error
> >
> >> 
> >> > what we had before was too many complex memory operands, yasm does not
> >> > support that in the first place.
> >> 
> >> Eh what?  Yasm is an assembler.  You do your own register allocation
> >> there.  That is why it is superior, among other reasons.
> >
> > Nothing stops you from allocating your registers in gcc yourself either.
> 
> That would be very counter-productive.  You'd end up with gcc spilling
> all the registers before the asm block and reloading them after.  Not
> good.

there is "%r"
btw with yasm you can add pushing on the stack call, loading off the stack
return thats not better and for teh ABIs where things are passed in registers
you will have the same spilling

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100120/c7d5a091/attachment.pgp>



More information about the ffmpeg-devel mailing list