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

[Trent Piepho]

On Wed, 8 Nov 2006, Michael Niedermayer wrote:
> On Tue, Nov 07, 2006 at 07:38:01PM -0800, Trent Piepho wrote:
> [...]
> > > > 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.
>
> my argument has always been about the specification of asm in the docs
> not the limitations of specific implementations
> asm code in mplayer and ffmpeg must conform to the asm
> specification in the docs if it does not it is rejected

The gcc docs specifically say that "+" should not be used with memory
operands.  Yet lavc has code which uses "+m", in violation of the
specification in the docs.  So why is that ok?  Because it works, even
though the docs say not to do it?

You said, "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 "=&..."."  The gcc docs
say this too.  Yet I see this code in h264_loop_filter_luma_mmx2:

asm volatile(
...
"movq      %%mm7, %0       \n\t"
...
H264_DEBLOCK_P0_Q0(%8, unused)
...
: "=m"(*tmp0)
: "r"(pix-3*stride), "r"(pix), "r"((long)stride),
  "m"(*tmp0/*unused*/), "m"(*(uint32_t*)tc0), "m"(alpha1), "m"(beta1),
  "m"(mm_bone)

Look at that, the code modifies %0 before it uses %8!  According to you,
this must not be done because %0 could be the same as %8.  Why is this code
allowed?  Who wrote this anyway?  I wonder what they were thinking when
they put "m"(*tmp0/*unused*/) in there?  Surely you would never write
something like that?  When will this be changed to use the required form of
"=&m"(*tmp0), even though that doesn't compile?

> >  "=&m" won't even compile!
>
> and past versions of gcc also failed compiling various things in the c
> standard, still that didnt affect what is valid c and what is not it was
> just that gcc was broken

Do you write code that will work on the compiler you have, or code that
only works on the compiler you wish you had?  With the former, you get a
working program, with the later, you get a program you wished worked.

> > When you
> > said "=m"(a), "0"(a) is equivalent to "=m"(a), "m"(a) you were wrong.
>
> i did not say this
> i said:"
> fact seems to be gcc due to limitations of its architecture cannot
> copy or move a variable to another memory locations, and with this
> additional limitation of the current gcc implementation
> "=m"(a), "0"(a) is equivalent to "=m"(a), "m"(a)
> this is NOT guranteed by the gcc docs and neither is it gurateed to
> work in the futur
> "

Looks like you said that too me.  I quoted it character for character.  You
said in the current gcc implementation they are equivalent, but they aren't
equivalent in the current implementation.

> > Try compiling this with -O0 and see which "equivalent" function fails
> > to compile:
>
> i see, but gccs ability to compile code is not related to the validity of
> the code, and iam just repeating here what ive been told by one of the
> most authorative and always correct divine gcc developers:

You can write an asm statement with 30 register outputs.  There is nothing
in the docs that say this is invalid.  On MIPS, it may even compile.  But
on ia32, it will never compile and there is no way gcc could ever compile
it.  Just because code is _sytactically_ valid, doesn't mean gcc has the
ability to compile it, or that valid solution even exists for a given
machine.