[MPlayer-dev-eng] Improved remove-logo filter
Trent Piepho
xyzzy at speakeasy.org
Fri Nov 10 02:43:48 CET 2006
On Wed, 8 Nov 2006, Uoti Urpala wrote:
> On Mon, 2006-11-06 at 03:20 -0800, Trent Piepho wrote:
> > On Mon, 6 Nov 2006, Uoti Urpala wrote:
> > > > It needs "memory" on the clobber list, or better
> > > > yet, "=m"(x) as an output.
> > >
> > > ... except that if "=m" cannot point to an alias of the variable, your
> > > "better" alternative is a bad idea since it requires allocating a
> > > register to hold &x unless x is a stack variable or similar that can be
> > > accessed without needing an explicit pointer.
> >
> > You're wrong about that. Try it.
>
> About what? Depending on what x is having "=m"(x) in the output list
About what you said, "it requires allocating a register to hold &x unless x
is a stack variable or similar."
I posted an example, which you edited out, of gcc using the same register
for "=m"(x) and "r"(&x) when x was not a stack variable. You said this
could not be done, but I posted an example that proves that wrong.
> does require an extra register; I have tested that. Probably best would
> be for gcc to support memory variables in the clobber list, but
> currently it doesn't.
If you've tested it, where is your example? I posted two that support my
claim, you've posted none that support yours. If you have "r"(&x) as an
input (not an input/output) and add "=m"(x) as an output, gcc will be able
to use the same register for both. You might need to turn optimization on,
but you really can't expect gcc to come up with an good register allocation
if you've disabled it's ability to look for one.
If you subsitute some complex expression for x, gcc's CSE may not be able
to figure out that registers will be the same, and will use different ones.
You can always help CSE along by assigning &(whatever expression) to some
temporary pointer, and then uses (*that_pointer) as the memory operand.
> > > I've already explained this exact thing TWICE. Are you retarted or what?
> > > If you need side effects which don't directly affect the current thread
> > > to happen then you must specify "volatile". This is true even for plain
> > > C, without any asm whatsoever.
> >
> > And I already explained to you that you are wrong about what volatile
> > means. It just means that all the loads and stores implied by the code
> > must exist. If you write this:
>
> gcc cannot guarantee that all the loads and stores in asm exist if it
> uses a copy of the variable. The asm can do multiple loads or stores and
The asm is just a black box to gcc. It doesn't make any guarantees about
that the asm does or does not do.
It only needs to have the loads and stores in the code in the order defined
by the sequence points. If you have x<<=1 in your code and x is volatile,
gcc is free to make all the copies of x is wants and operate on those
copies. It just needs to have the load and store in the proper place in
relation to the code around it.
There is nothing in the definition of volatile, or in the gcc docs about
inline asm, that says a volatile operand to an asm constuct may not be a
copy. Volatile _is_ defined, and that is not the definition!
They could decide to overload the meaning of volatile (and overloading the
meaning of iso defined keywords is frowned on!) specificly as it relates to
inline asm and memory operands, but they have not done so.
> > You may wish that the way gcc worked is that if an asm has a volatile
> > operand, then a memory reference (but not a register) must not be a
> > copy. But that is not how it works.
>
> It isn't? Do you have a counterexample with current gcc? Anyway the
> exact method you should use isn't that important; my point is that there
> is no reason for gcc to handle asm as if every variable was always
> volatile when it doesn't handle C that way.
I've posted an example before.
volatile int x;
asm("" : "+r"(x));
it compiles fine, yet the asm is given a copy of x. It works fine because
volatile does not mean that temporary copies of variables can't be made and
then operated on. Read C99, the definition of volatile does not require
what you say it does.
More information about the MPlayer-dev-eng
mailing list