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

[Trent Piepho]

On Sat, 4 Nov 2006, Michael Niedermayer wrote:
> On Fri, Nov 03, 2006 at 08:13:37AM -0800, Trent Piepho wrote:
> [...]
> >
> > > Are you really seriously arguing that gcc should disable all
> > > optimizations in a function if there's any asm? That it must not keep
> > > variables in registers since original memory copy of the variable could
> > > be changed from outside etc?
> >
> > Where did I say anything like that?  I said that in order to be able to
> > write atomic operations, gcc must make "m" constraints not be copies, but
> > the actual variable.
>
> 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?

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

Try "=m":"0" with gcc 4.x.  It will give you a warning.

In gcc 3.x versions, "+m" does not work properly. Try it with gcc ~ 3.5 - 3.6,
and it will produce a warning.

> >
> any problems with "=m"/"0" then gcc should convert this to whatever equivalent
> does not cause problems if "=m"/"0" is equivalent to "=m"/"m"in current gcc
> implementations then gcc should convert it to that

As I quoted before, this requires the optimizer to do CSE and determine
that both the input and output are the same thing.  At some point the
expressions will become too complex to do this.  This is why gcc will
produce a warning if you try to use "=m":"0".

> > I provided a quote from a gcc
> > developer about why it doesn't work properly.
>
> i can provide you with quotes from gcc developers claiming that
> finite == infinite and similar

In that case, can you find any to support your position?

> so to summarize, please correct me if iam wrong
> "=m"/"m" works best on most gcc versions according to you, it according
> to you and one gcc developer is guranteed to have both pointing to the same
> spot in memory while nothing? in the gcc docs would support such a view and
> consequently according to the docs has undefined bahavior
>
> so until the gcc docs contain a gurantee that "=m"(a)/"m"(a) will always
> point to the same spot in memory, i assume that this is not guranteed
> 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.