[FFmpeg-devel] pre discussion around Blackfin dct_quantize_bfin routine

[Reimar Doeffinger]

Hello,
On Tue, Jun 12, 2007 at 04:44:30PM -0400, Marc Hoffman wrote:
> On 6/12/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > Hello,
> > On Tue, Jun 12, 2007 at 12:22:02PM -0700, Trent Piepho wrote:
> > [...]
> > >   uint64_t lo, hi;
> >
> > must use uint32_t, otherwise D and W constraints fail
> >
> > >   asm volatile ("%0=cycles; %1=cycles2;" : "=D"(lo), "=W"(hi));
> >
> > This result in the usual, and at least to me very well known stupidity
> > of gcc (also known as "how to do nothing in many steps"):
> > it really believes that adding, oring and multiplying by 0 is
> > worth it. That is probably because in the highlevel optimizations they
> > do these are not present, they only crop up after they have done all
> > optimizations... An impressive point why machine independant
> > optimization is stupid.
> >
> >  5c0:   00 e8 00 00     LINK 0x0;
> >  5c4:   86 31           R0=CYCLES;
> >  5c6:   9f 31           R3=CYCLES2;
> >  5c8:   01 60           R1=0x0(x);
> >  5ca:   02 60           R2=0x0(x);
> >  5cc:   10 56           R0=R0|R2;
> >  5ce:   59 56           R1=R1|R3;
> >  5d0:   01 e8 00 00     UNLINK;
> >  5d4:   10 00           RTS;
> 
> Kidding aside I think the compiler is just a little confused here
> thats all. Someone would probably need to fix this someplace other
> than inside of ffmpeg.

This issue appears consistently when using types that are larger than
the native size, at least with RISC. x86 might work better since those
nonsense operations there compile into a single NOP instruction that
might be easier to eliminate.
Maybe I should finally report a bug about this to gcc, this kind of
thing can really bloat code big time on 8 bit architectures.

Greetings,
Reimar Doeffinger