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

[Michael Niedermayer]

Hi

On Fri, Nov 03, 2006 at 11:53:13PM -0800, Trent Piepho wrote:
> 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?

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

ok solution, just ensure that the variables are on the stack, or are
parameters to the function right? the problem here is
1. extra dummy variables (even unused IIRC) slow code down (yes i have 
   benchmarked it, and no i dont know why)
2. the optimizer can remove your dummy variables or inline the function
   again yes i have seem code which gcc failed to allocate registers for
   if attribute(noinline) wasnt used

... the optimizer should never break code ... IMO ...

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


> 
> > > > > 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
and the specification (gcc docs) dont support this, i simply dont care what
current gcc does internally, as a user i shouldnt even have to know it
its the specification of the syntactical and semantical rules i need to care
about ... and what gcc does internally also changes at will of the gcc
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 ...


> 
> Try "=m":"0" with gcc 4.x.  It will give you a warning.
> 
> In gcc 3.x versions, "+m" does not work properly. 

maybe in early gcc 3.x versions (which arent used by many people anymore)
and gcc had many asm related bugs, iam not at all saying +m was less buggy
then everything else related to asm


> Try it with gcc ~ 3.5 - 3.6,
> and it will produce a warning.

it does produce one, but so does gcc for many other things which are entirely
valid without any doubt
the warning doesnt say why "=m"/"0" is not recommanded, it could be a 
limitation of the current gcc implemenation or problems with it in past 
implemenattion, if its not legal gcc could say so in the warning, it does not

try a "//" with -pedantic, gcc will tell you exactly why its bad
"warning: C++ style comments are not allowed in ISO C90"


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

if "=m"(a)/"0"(b) has undefined behavior (we all seem to agree on that more
or less, and gcc doesnt compile it currently anyway) then gcc does not need
any CSE to awnser if "both the input and output are the same thing" the 
awnser yes will work fine, so this seems another gcc developer comment which
is fundamentally wrong (iam scared by how few things they say are not self
contradicting)


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

the docs of gcc ...
which are what i would consider to be the most official standpoint


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

if linus jumps out of the window will you follow him? and anyway our
interpretations of linus replies dont seem to match

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is