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

[Trent Piepho]

On Sun, 5 Nov 2006, Michael Niedermayer wrote:
> On Fri, Nov 03, 2006 at 11:53:13PM -0800, Trent Piepho wrote:
> > On Sat, 4 Nov 2006, Michael Niedermayer wrote:
> > > no, there just needs to be any syntactical way to say "dont copy this anywhere
> > > and give me the real location" this can be volatile or "m" or anything else,
> > > its the decission of the compiler developers
> > >
> > > if "m" has this additional (undocumented) constraint, its useless for anything
> > > but spinlocks and similar, and a "m2" would be needed for normal applications
> >
> > What makes it useless?
>
> well, look at all the asm gcc bugs on gccs bugzilla
> if gcc cannot copy "m" onto the stack and use it from there then it will end
> up with some problems if the number of "m" and "r" exceeds the number of
> registers minus the ones gcc cant use due to its architecture in case of PIC
> so with PIC and without -fomit-frame-pointer on x86 you are limited to 5 asm
> operands which is simply not enough

Which is the case (and what I have been saying all along):

int *a,*b,*c,*d, *e,*f,*g,*h;
void foo(void) {
asm volatile("# %0 %1 %2 %3\n\t# %4 %5"/*" %6 %7"*/ :
    "=m"(*a), "=m"(*b), "=m"(*c), "=m"(*d),
    "=m"(*e), "=m"(*f)/*, "=m"(*g) , "=m"(*h) */); }

gcc -Wall -O4 -S -fpic -fno-omit-frame-pointer test.c
test.c:3: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'

-fno-pic and -fomit-frame-pointer allow one more operand each.

> and copying variables onto the stack can improve speed alot, gcc svn does
> this according to uoti, maybe violating your dont copy constraint?

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.

If svn gcc can provide "=m" constraints with copies of variables, I'd like
to see an example.  And ask the gcc devs WTF one is supposed to do to write
a spin-lock.

> > > > > > 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.
> > >
> > > it will not give a warning on "+m" which was said to be the same as "=m"/"0"
> > > by at least one gcc developer in the thread you linked, furthermore if gcc has
> >
> > I'm sure you are reading that wrong.  "+m" has been made the same as "=m":"m".
> > It has not been made the same as "=m":"0".
>
> 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?

IMHO, this whole discussion of specification vs. implementation is you
trying to side-step the issue.

This all started when you said some of my asm code was wrong, and must be
written is some other form.  You mentioned specific forms that must be used
and certain problems that could happen.

I proved repeatedly, with examples of discussion of gcc bugs, examples of
gcc warnings and error messages, quotes from gcc developers, and quotes
from the gcc documentation, that the forms you said were necessary were
wrong and that problems you said could occur can't.

You no longer seem to trying to argue that I'm wrong with respect to how
past and present versions of gcc work.  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.

> developers, things which where legal in the past become illegal and the other
> way around, whats the current gcc implementation or the oppinion of the gcc
> developers simply is not that usefull, you cant use it to write code which
> will work in 5 years, as in 5 years there will be other people working on gcc
> and they will have another oppinion on what some things mean ...

So one should not write something that works with past and present versions
of gcc?  One should instead write something that has been proven to _not_
work in past and present versions of gcc because you believe that it may
become the correct way 5 years from now?

> > > yes the official docs are more authorative then 2 random people
> > > and so code which depends on such assumtations is consequently buggy and
> > > rejected
> >
> > I wouldn't call a gcc developer some random person.  If Linus trusts
> > Richard to tell him how gcc works, I'm inclined to trust him too.
>
> if linus jumps out of the window will you follow him? and anyway our
> interpretations of linus replies dont seem to match

I'm more inclined to believe a gcc developer, who knows how gcc works from
writing the code, that I am someone whose opinion comes from perusal of the
gcc docs.