Hi, On Fri, Apr 22, 2011 at 7:17 PM, Alexander Strange <astra...@ithinksw.com> wrote: > On Fri, Apr 22, 2011 at 6:38 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: >> This prevents gcc from assuming that contents of it may have changed >> between calls to vp56_range_get_prob(), thus preventing countless (and >> unnecessary) movs. Decoding of sintel trailer goes from (avg+SG) 9.796 >> +/- 0.003 to 9.635 +/- 0.010. >> >> This is admittedly a hack. > > h264_cabac turns this off for ARCH_X86, but I'm not sure that's merited.
Likely not, we should measure that. > Does the code get better or worse with gcc-4.2 x86-32? If it's better, > OK with me. before 10.602 10.587 10.629 after 10.413 10.436 10.437 Seems to win also. Alex (Converse) mentioned rightfully that I'm screwing around restrict breakage. I can change the patch - if wanted - to do this hack for early gcc versions and then for later systems with a functional restrict, use the real function with a proper VP56RangeCoder * restrict c argument. Unfortunately, my gcc still doesn't do anything remotely useful with restrict (gcc-4.2.1) >> - block[zigzag_scan[i]] = (vp8_rac_get(c) ? -coeff : coeff) * >> qmul[!!i]; >> + block[zigzag_scan[i]] = (vp8_rac_get(&c) ? -coeff : coeff) * >> qmul[!!i]; >> } while (++i < 16); > > Come back and make this branchless later. See get_cabac_bypass_sign(). OK, will mark for later. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
