[FFmpeg-devel] [PATCH] update doc/optimization.txt

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, Sep 21, 2010 at 11:13:38AM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Tue, Sep 21, 2010 at 10:36:02AM +0100, M?ns Rullg?rd wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> 
>> >> >> The function call overhead is exactly the same with yasm or C,
>> >> >> assuming the C compiler doesn't generate ridiculous prologues and
>> >> >> epilogues.  Please stop claiming anything else.  Nobody is talking
>> >> >> about asm that actually gets inlined.
>> >> >
>> >> > thats not true, the split asm cases surely where inlined and a 1:1
>> >> > conversion to yasm would have had additional call overhead.
>> >> 
>> >> Nobody ever suggested doing that.  We've always been talking about
>> >> whole functions, be they written C or yasm.  Now stop making straw man
>> >> arguments, please.
>> >
>> > you talk about optimizing C code to asm and converting inline
>> > to yasm both in one patch and use it as argument why yasm is better.
>> > But its the C->asm optimization that makes it better not inline->yasm
>> 
>> The split inline asm in the SSE IMDCT could not have been merged.
>> There was a function call to the FFT between the two parts, and on
>> x86_64 it is not possible to do a function call from within inline asm
>> (and it is a bad idea on any arch).  When the entire function is
>> written in yasm, there is of course no problem with making function
>> calls.
>
> interresting strawman argument
> noone was talking about cases that cannot easily be done in inline asm

So why are they split in the first place?

> not that calling from inline would be impossible or anything

Calling a function from inline asm on x86_64 (and ppc64) is impossible
to do safely due to the red zone on the stack.  The compiler must be
aware of the function call happening, or you will get stack corruption.

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