[Ffmpeg-devel] [PATCH] fix build for --cpu=i686

[Trent Piepho]

On Wed, 28 Mar 2007, Michael Niedermayer wrote:
> > Index: libavutil/internal.h
> > ===================================================================
> > --- libavutil/internal.h	(revision 8535)
> > +++ libavutil/internal.h	(working copy)
> > @@ -230,7 +230,7 @@
> >      "cmovl %3, %0       \n\t"\
> >      "cmovl %4, %1       \n\t"\
> >      "cmovl %5, %2       \n\t"\
> > -    : "+r" (x), "+r" (a), "+r" (c)\
> > +    : "+r" (x), "+&r" (a), "+&r" (c)\
> >      : "r" (y), "r" (b), "r" (d)\
>
> hmm, could someone ask the gcc devels if "+r" are supposed to be able
> to overlap "r" ?

AFAIK, the only rule about operand overlapping is that output operands
can't overlap each other and that earlyclobber operands can't overlap input
operands.  But, this overlapping only applies to registers!  This would be
why only register operands can be made earlyclobber.  An operand _in_ a
register can't use the same register that another operand is in or uses:

%eax    and  %eax      overlap
%eax    and  4(%eax)   overlap
8(%eax) and  4(%eax)   no overlap
8(%eax) and  8(%eax)   no overlap, 8(%eax) is not a register!

Anyway, gcc can merge two variables into one variable if it knows both
have the same value.  In this way, two different input operands to an asm could
use the same register.  If one of these is also an output, nothing is wrong.
For example:

void foo(void)
{
    int a=1,b=1,c=1,d=1;
    asm volatile("# %0 %1 %2 %3" : "+r"(a), "+r"(b) : "r"(c), "r"(d));
}

In this case, gcc knows that a,b,c and d are all one.  It doesn't need to
supply two different registers for c and d, it can just use the same one
for both.  a or b could also share this register, but a and b can't be in
the same register since they are both outputs.  And in fact, gcc does this:

foo:
        movl    $1, %eax        #, tmp60
        movl    %eax, %edx      # tmp60, b
#APP
        # %eax %edx %eax %eax   # a, b, tmp60, tmp60
#NO_APP
        ret

gcc puts a, c, and d in %eax, and b in %edx.

> though either way the change is wrong, the early clobbers would have to
> be on the first and second not second and third

Of course.