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

[Trent Piepho]

On Tue, 7 Nov 2006, Michael Niedermayer wrote:
> > It sounded to me like what Uoti found was an asm construct that modified a
> > variable through a pointer with out telling gcc about it.  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.
>
> "=m" needs an additional register in some cases (the ones where no not
> modified register points to it or to a constant offset from it)

True, if "r"(p) was an output instead of an input gcc wouldn't be able to
use the same register.  In that case there is no good way to tell gcc you
are going to dereference a pointer, without either using extra regsiter(s)
with "=m" or having gcc re-load everything with "memory".

> > > you really seems to be intentionally trying to sidestep the issue, its not
> > > what gcc does, it is what something means and what its guranteed to do, its
> > > a question of specification vs. implementation
> >
> > Suppose the docs are not some kind of specification that the inline asm
> > extension was written to follow, but the other way around.  That the inline
> > asm extension is just a way to access gcc's internal structures.  That the
> > docs are just an attempt to document how to make use of gcc's internal
> > workings.  Have you considered that?  Maybe future versions of gcc will not
> > have an asm extension that works differently, but different documentation?
>
> as the gcc developers can change both gcc and the docs at will they could
> of course do anything, if changing well written and logic docs to match
> the current limitations of the implementation is wise or professional
> is another question but they of course could do it

It's one thing to say the implementation should match what some
documentation says, it's another thing to actually write the code that does
it.  It could be that creating a compiler that works the way you interpret
the docs isn't realistic.

> > IMHO, this whole discussion of specification vs.  implementation is you
> > trying to side-step the issue.
>
> if you see it that way so be it, we cannot rewrite all asm to match a
> possibly changing implementation, our asm matches the specification(=gcc
> docs) if the asm gcc docs are changed then we will likely put some effort
> in finding alternatives to gcc which have a more stable asm specification
> until then future gcc versions wont be supported if they fail with our
> code this isnt a big issue considering the amount of improvments since
> gcc 2.95

The gcc 4.2 docs say you shouldn't use "+m".  Are you going to ignore that?

If the docs to an older version of gcc don't say that "x" isn't allowed,
but it is a known bug that "x" will not work in that version of gcc, and
there is a perfectly good alternative that does work and has no drawbacks,
shouldn't the alternative be used?  Attribute the bug to a flaw in gcc's
code or an omission in the documentation as you will, it still remains that
"x" doesn't work and perfectly good alternative does.

>
> > You have instead dismissed this as irrelevant, and claimed what is
> > relevant is how you think future versions of gcc will work.  At that
> > point it is no longer a discussion of facts, but one of opinions.
>
> you repeated many times how different gcc versions had difficulty with
> specific asm constructs which where working with others, you yourself
> claimed with that that gccs interpretation and implementation of asm
> changes confirming what i said now it doesnt fit into your newly twisted
> argumentation so you claim the opposit

My argument has always been that my claims about what asm constructs will
work with past and present gcc versions and which will not work are
correct.  Where you have disagreed with me about that, you have been wrong.
When you said that one must use "=&m" to keep a memory operand from
overlapping an input, you were wrong.  "=&m" won't even compile!  When you
said "=m"(a), "0"(a) is equivalent to "=m"(a), "m"(a) you were wrong.  Try
compiling this with -O0 and see which "equivalent" function fails to
compile:

int *p, x;
void foo(void) { asm("# %0 %1": "=m"(*(p+x*x)): "m"(*(p+x*x))); }
void bar(void) { asm("# %0 %1": "=m"(*(p+x*x)): "0"(*(p+x*x))); }