[FFmpeg-cvslog] r18936 - in trunk/libavcodec: Makefile mlpdsp.c

[Reimar Döffinger]

On Mon, May 25, 2009 at 04:42:28PM -0300, Ramiro Polla wrote:
> I still don't really understand what llvm is complaining about, but is 
> there a way to make llvm stop complaining without altering the object 
> code in gcc? There should be a way to correctly specify this...
> 
> Besides, how bad can a cast to the same type be?

Sorry, I missed that readval is "r" for 64 bit.
In that case, I think that's a bug in LLVM, it should ignore nop-casts
(the types are exactly the same).
Alternatively, you could change the READVAL macro to include the cast.
Though I think it would really be a good idea to go over all those
constraints and check them, because if not plain wrong they are at least
silly, e.g.

> @@ -166,7 +167,7 @@
>            /* 2*/"+r"(sample_buffer),
>            /* 3*/RDWRVAL(blocksize)
>          :
> -          /* 4*/READVAL((x86_reg)mask),
> +          /* 4*/READVAL(mask_reg),
>            /* 5*/READVAL(firjump),
>            /* 6*/READVAL(iirjump),

Why force firjump and iirjump into a register ("r") instead of allowing
both register and reference ("g")?

> #if ARCH_X86_64
>         , /* 8*/"r"((int64_t)coeff[0])
>         , /* 9*/"r"((int64_t)coeff[1])
>         , /*10*/"r"((int64_t)coeff[2])
> #endif /* ARCH_X86_64 */

Why isn't READVAL used, at least for consistency?
Why int64_t and not x86_reg?
Wouldn't it maybe have been more readable to put all the constraints
that differ under #if ARCH_X86_64 instead of having a RDWRVAL, READVAL
and COUNTER macro _and_ still needing the if (I admit it is a bit of
code duplication...)