[FFmpeg-devel] [PATCH] replace hardcoded offset of CABACContext.bytestream with "m" operand

[Michael Niedermayer]

On Mon, Mar 17, 2008 at 10:56:06PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Mar 17, 2008 at 09:01:20PM +0000, Mans Rullgard wrote:
> >> ---
> >>  libavcodec/cabac.h |   54 ++++++++++++++++++++++-----------------------------
> >>  1 files changed, 23 insertions(+), 31 deletions(-)
> >
> > Have you checked that gcc doesnt pessimize the code? Iam certain this
> > was written the way because it didnt work the other (cleaner) way around
> >
> > I also like to see START/STOP_TIMER benchmarks. In adition to some
> > confirmation that gcc still uses the same register for (c) and
> > (c->bytestream)
> 
> GCC 4.1.2 gives exactly the same code for the modified parts.  There
> are, however minor differences in other parts of code.  In some
> places, it has used r13 instead of r12, and instructions are reordered
> in seemingly random ways in a few places.  Full diff of disassembled
> output (h264.o) attached.  GCC is a mystery indeed.

Ok, gcc 4.1.2 looks good, what about the other versions (4.2, 4.3, 3.4, 2.95)?


> 
> > And some confirmation that it doesnt cause failures or miscompilations on
> > gcc 2.95 and 3.* (3.3/3.4 being most relevant)
> > old gcc is very sensitive to the number of operands
> 
> There's that of course...

I dont understand what you mean?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080318/7fa6b2cc/attachment.pgp>