[MPlayer-dev-eng] Improved remove-logo filter

[Trent Piepho]

On Fri, 3 Nov 2006, Uoti Urpala wrote:
> On Thu, 2006-11-02 at 15:22 -0800, Trent Piepho wrote:
> > And in order to be able
> > to write one in asm, you need to be able to modify a non-copy of a
> > memory location.
>
> I already explained once that you can use the volatile keyword for
> this...

That's not how it works...  Say I write this:

volatile int x;
asm("# atomic test and set %0" : "+r"(x));

Obviously x must be copied into a register.  It's volatile, yet the asm
instruction gets a copy.  Obviously, this won't work for a spin-lock.

volatile just means that all the loads and stores implied in the code must
be present.  gcc can copy all the inputs to a new location before an asm
block, and then copy all the outputs back out after the block, and this
satisfies volatile.  This isn't enough for something like a spin-lock.

> Are you really seriously arguing that gcc should disable all
> optimizations in a function if there's any asm? That it must not keep
> variables in registers since original memory copy of the variable could
> be changed from outside etc?

Where did I say anything like that?  I said that in order to be able to
write atomic operations, gcc must make "m" constraints not be copies, but
the actual variable.

> > Did you read the same thread I did?
> >
> > "=m"(x) : "0"(y)  isn't allowed, as a and b can't be in the same location.
>
> I'm not sure exactly what you're arguing for in here and the rest of
> your message, but I think it's not about the same thing as your original
> disagreement with Michael.

Michael said don't use [out]"=m"(a):[in]"m"(a), use [out]"=m"(a):[in]"0"(a)
or [inout]"+m"(a).

This is wrong.

First, the form with the "0" will not always work properly.  gcc (> ~3.5)
will give you a warning if you even try.  I provided a quote from a gcc
developer about why it doesn't work properly.

Second, the "+" form wasn't supported on old gcc, and gcc in the 3.x range
would sometimes mis-compile it.  I provided links to gcc and openbsd
developers commenting on the existance of these bugs in gcc.

Third, I provided a quote from a gcc developer that "=m":"m" is the
_preferred_ form, and not, as Michael said, something that must not be
used.