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

[Trent Piepho]

On Fri, 10 Nov 2006, Uoti Urpala wrote:
> On Thu, 2006-11-09 at 17:43 -0800, Trent Piepho wrote:
> > On Wed, 8 Nov 2006, Uoti Urpala wrote:
> > > > > 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."
>
> What I said was "or similar that can be accessed without needing an
> explicit pointer".

Which is what I provided an example of.

>
> > 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
>
> I wasn't talking about "=m"(x) and "r"(&x). It was about a case where
> asm was modifying x but the code failed because gcc was using a stack
> copy of x instead of the original variable which was modified (x didn't
> appear in the asm constraints at all in this case).

I think you need to go back and look at the message you replied to:

> Something like:
>
> int x, *p = x;
> asm("movl $0, (%0)" : : "r"(p));

> Of course something like that will not work, because gcc doesn't know the
> value of x has changed.  It needs "memory" on the clobber list, or better
> yet, "=m"(x) as an output.

That is what I wrote.  I was talking "=m"(x) and "r"(&x).  You then replied
to my message, and tried to correct me:

> 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 were wrong when you said that, and I've posted examples that prove it.
If you've tested it as you say, why don't you provide your test case?

> Btw the asm in cabac.h which has "r"(c) in input arguments still
> compiles after adding "=m"(c->low) to the output arguments if you
> disable inlining, but runs out of registers with inlining enabled...

struct foo { int a, b; } *p;
void foo(void) { asm("# Got %0 and %1": "=m"(p->b): "r"(p)); }

#APP
        # Got 4(%eax) and %eax  # <variable>.b, p.0
#NO_APP

Uses the same register.

> > could not be done, but I posted an example that proves that wrong.
>
> You proved that a claim you made up yourself was wrong. I was neither
> talking about "=m"(x): "r(&x) nor claimed that strictly everything
> except stack variables would require extra registers.

Go back and look at the thread.  I was talking about "=m"(x):  "r"(&x), you
said (incorrectly) I was wrong.

> > It only needs to have the loads and stores in the code in the order
> > defined by the sequence points.
>
> So your argument is still that if the standards do not directly
> guarantee that certain constructs disable optimizations which you might
> not want to use in some cases then the optimizations must _always_ be
> disabled?

What really happens is that gcc doesn't support that optimization.  But if
it did, there is nothing in the definition of volatile, and it is defined,
that would disable it.

> > > > 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

Here's an idea.  If you think an lvalue as a memory operand to an asm can
be a copy, come up with an example of one.  Then see if volatile makes any
difference.

> > > 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));
>
> And what is that an example of? Of course a register argument based on a
> variable in memory is a copy, but you were talking about "a memory
> reference (but not a register)". "+r" does not look like "not a
> register".

I shows that volatile does not mean that an operand to an asm statement may
not be a copy.  If you think volatile has been extended to have an extra
meaning with respect to memory a reference (but not a register), then where
is that documented?