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

[Michael Niedermayer]

Hi

On Wed, Nov 01, 2006 at 03:42:30AM -0800, Trent Piepho wrote:
> On Wed, 1 Nov 2006, Michael Niedermayer wrote:
> > On Tue, Oct 31, 2006 at 01:13:29PM -0800, Trent Piepho wrote:
> > > On Tue, 31 Oct 2006, Guillaume POIRIER wrote:
> > >
> > > > Hi Trent,
> > > >
> > > > Were you able to work on improving your patch?
> > >
> > > What was there to do?  Change the asm to use "+" constraints
> > > even though it doesn't always work with gcc 2.7.2?
> >
> > does gcc 2.7.2 compile mplayer at all?
> 
> Sorry, I meant 2.95, but I'm not sure if that's the case.  Some older gcc
> docs explictly say you can't use "+", newer ones say you can, but with
> various conditions (which change from version to version).
> 
> You might also want to look at these threads:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107475162200773&w=2
> http://lkml.org/lkml/2006/7/8/251
> 
> Using "+m" vs "=m"/"m" is a complex issue.
> 
> >
> > and if you use "=something" then you should also be aware of that for example
> >  "=r"(a)
> > :"r"(b)
> >
> > does not prevent %0 == %1 if you want an output to not be able to use the
> > same register or memory location as an random input then you must use "=&..."
> > iam not sure if that could cause any problems with your code as i didnt look
> > at it, just the constraints quoted above in which "=m" (accumulator) and
> > "m" (accumulator) could be in the same memory location or a different one
> > or "=m" (accumulator) and "g" (stride) could be in the same memory location
> 
> How could accumulator be in two different memory locations?

an opimizing compiler can make a copy, for example it could copy it to
the stack, gcc may or may not be capable of that but that doesnt matter
for the validity of the code ...
also note that we had very significant speed gains from manually copying
the cabac stuff in h.264 onto the stack so this is not a silly choice
and the question why use one as input and one as output?
well one might be somewhere (not the stack) but hold the uptodate value
and one miht be on the stack and be the one used by later code


> 
> How could two variables (accumulator and stride) share the same memory
> location?

well, stride might be unused after the asm, and the optimizer might choose
to reuse the spot in memory
and the question is not why the compiler might choose to do something but
rather that there is no rule which prevents the compiler from doing that


> 
> Before you say gcc could allot some new memory and copy the variables in
> and out, please read the message from Richard Henderson that I linked to
> that explains why this can't be done.

yes i read it, i also read linus reply which basically said 
"Please fix the compiler"


> 
> Anyway, accumulator isn't written to before all the inputs are consumed, so
> it's not an "early-clobber" output and wouldn't need an '&' if it was "=r"
> instead of "=m" 

ok


> (a memory output can't overlap an unrelated input.  A
> register output can overlap a memory input, but not the other way around).

maybe true for current gcc implementations maybe not, i dont know but i
doubt this is what the docs say, furthermore such a limitation is technically
stupid and inappropriate for a optimizing compiler, and iam not going
to write asm code based on limitations of gccs architecture while they would
be invalid in the general case (according to the docs of gcc)

[...]

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