[FFmpeg-devel] [PATCH 1/5] Shrink the size of vp56_mv

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Tue, Jun 15, 2010 at 08:09:46PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> 
>> > On Tue, Jun 15, 2010 at 04:58:14PM +0200, Aurelien Jacobs wrote:
>> >> On Tue, Jun 15, 2010 at 09:02:14AM -0400, David Conrad wrote:
>> >> > ---
>> >> >  libavcodec/vp56.h |    4 ++--
>> >> >  1 files changed, 2 insertions(+), 2 deletions(-)
>> >> > 
>> >> > diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
>> >> > index 89eba05..3d98b9e 100644
>> >> > --- a/libavcodec/vp56.h
>> >> > +++ b/libavcodec/vp56.h
>> >> > @@ -60,8 +60,8 @@ typedef struct {
>> >> >  } VP56RefDc;
>> >> >  
>> >> >  struct vp56_mv {
>> >> > -    int x;
>> >> > -    int y;
>> >> > +    int16_t x;
>> >> > +    int16_t y;
>> >> >  };
>> >> 
>> >> Looks OK. Apply if you're sure that it can't overflow.
>> >
>> > Hm, might make sense to benchmark a bit, it might be slower e.g.
>> > if it means a lot of sign extension is added to the code...
>> 
>> What CPU can't load signed half-words from memory?
>
> In addition to what Michael said:
> That doesn't help if e.g. there's some code like
> mv->x = ...(some int)
> if (mv->x ...)
> for which this change would result in useless sign extension.

Unless the compiler manages to prove it's not needed.  GCC may or may
not do that.  Why don't you compile it both ways and compare code size
if you care that deeply?

My suspicion is that reduced cache pressure will gain some speed even
if a few extra instructions are added somewhere.

-- 
M?ns Rullg?rd
mans at mansr.com