[MPlayer-dev-eng] Improved remove-logo filter
Uoti Urpala
uoti.urpala at pp1.inet.fi
Fri Nov 10 05:15:33 CET 2006
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".
> 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).
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...
> 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.
> 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?
> > > 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));
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".
More information about the MPlayer-dev-eng
mailing list