[FFmpeg-devel] [PATCH] Fix apply_welch_window_sse2 compilation on Mac OS X/x86

Pierre d'Herbemont pdherbemont
Thu Oct 18 10:56:04 CEST 2007


On Oct 18, 2007, at 2:23 AM, Trent Piepho wrote:

> On Thu, 18 Oct 2007, Pierre d'Herbemont wrote:
>> On Oct 17, 2007, at 10:05 PM, Loren Merritt wrote:
>>
>>> But I don't think the fix is correct: It's not valid to jmp from
>>> one asm block to another. If you split the asm block, you also have
>>> to write the loop part in C. And the reason I put it in asm is that
>>> gcc doesn't generate as efficient a loop.
>>
>> There is no problem in jumping from one asm block to an other.
>> However there can be problem with labels.
>
> Suppose gcc _did_ spill a register to the stack?

Right. But again, in this case, we are only assuming that %xmmx  
registers won't be messed up, we have don't use the stack directly,  
nor any general registers. We may not rely on this for sure.  
Experience prove that in this case it just work.

> You also have no guarantee that gcc won't mode code around so that  
> what was
> before or after an asm is now on the other side.  And no, making  
> the asm
> volatile does not work!  Suppose you code this:
>
> for(i=0;i<100;i++) {
>    asm volatile("1: ..." : : "=r"(i));
>    asm volatile("... je 1b" : :);
> }
>
> gcc might decide the perfect place to put the i++ is between the  
> two asm
> blocks, which will completely mess up the for loop, since now i is
> incremented inside the asm loop.

I am not sure of that. Since we are using "=r"(i), gcc can't put the i 
++ part afterwards. Or that's a bug.
Again, in our specific case we don't have that kind of problem anyway.

Thanks,

Pierre.




More information about the ffmpeg-devel mailing list