[FFmpeg-devel] [PATCH 3/5] startcode: Stop overreading

[Michael Niedermayer]

On Mon, Jun 03, 2019 at 10:45:00PM +0000, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Sun, Jun 02, 2019 at 12:47:17AM +0200, Andreas Rheinhardt wrote:
> >> Up until now ff_startcode_find_candidate_c could overread; it relied on
> >> zero-padding after the buffer in order to function correctly. This has
> >> been changed: No overreads occur any more.
> >> The ultimate goal behind all this is to create a high-performance
> >> function for searching of startcodes that can be applied even in
> >> scenarios where the buffer is not padded.
> >>
> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
> >> ---
> >>  libavcodec/startcode.c | 5 +----
> >>  1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/libavcodec/startcode.c b/libavcodec/startcode.c
> >> index 373572365b..b027c191c0 100644
> >> --- a/libavcodec/startcode.c
> >> +++ b/libavcodec/startcode.c
> >> @@ -41,10 +41,7 @@ int ff_startcode_find_candidate_c(const uint8_t *buf, int size)
> >>  
> >>  #define READ(bitness) AV_RN ## bitness ## A
> >>  #define MAIN_LOOP(bitness, mask1, mask2) do {                              \
> >> -        /* we check p < end instead of p + 3 / 7 because it is
> >> -         * simpler and there must be AV_INPUT_BUFFER_PADDING_SIZE
> >> -         * bytes at the end. */                                            \
> > 
> >> -        for (; buf < end; buf += bitness / 8)                              \
> >> +        for (; buf <= end - bitness / 8; buf += bitness / 8)               \
> > 
> > is this faster than subtracting  bitness / 8 from end outside the loop ?
> > if not then i would suggest to do it outside as that means 1 thing less
> > the compiler has to optimize out
> > 
> > thx
> In my tests the compiler calculates end - bitness / 8 only once and
> puts it in a register of its own. But I can do it manually, of course.

A compiler also can change between pointers and indexes, yet you change
that by hand in a previous patch. (so it seems the compiler must have
failed there with a trivial and expected optimization)
I think if one optimizes code at the level of detail that you do here
its better not to depend on the compiler more than needed for optimizing
things on top

Thanks

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190604/e7564baf/attachment.sig>