[FFmpeg-cvslog] r12165 - trunk/libavcodec/dsputil.c

[Rich Felker]

On Thu, Feb 21, 2008 at 09:22:20AM -0700, Loren Merritt wrote:
> On Thu, 21 Feb 2008, Rich Felker wrote:
> 
> > On Thu, Feb 21, 2008 at 08:56:40AM -0700, Loren Merritt wrote:
> >>>> Modified: trunk/libavcodec/dsputil.c
> >>>> ==============================================================================
> >>>> --- trunk/libavcodec/dsputil.c	(original)
> >>>> +++ trunk/libavcodec/dsputil.c	Thu Feb 21 08:54:46 2008
> >>>> @@ -50,6 +50,9 @@ void ff_add_png_paeth_prediction(uint8_t
> >>>>  uint8_t ff_cropTbl[256 + 2 * MAX_NEG_CROP] = {0, };
> >>>>  uint32_t ff_squareTbl[512] = {0, };
> >>>>
> >>>> +static const unsigned long pb_7f = 0x7f7f7f7f7f7f7f7fUL;
> >>>> +static const unsigned long pb_80 = 0x8080808080808080UL;
> >>>
> >>> Wouldn't it be faster to put these constants inline in the code
> >>> instead of as 'static const'?
> >>
> >> gcc does that. Any value derivable at compile time is equivalent to an
> >> inline constant.
> >
> > This is surely not traditional compiler behavior; if your intent is to
> > have them inlined then preprocessor constants or literals are
> > preferred.
> 
> Is constant propogation a recent invention?

The const keyword in C is not as strong as in C++. Historically it was
just a hint for warning generation and binary sectioning. C99
(possibly also C90?) add some teeth but I think it's still iffy to
consider const-qualified variables as real constants. They're not
usable in certain contexts where a constant is required.

> > Even if gcc does optimize them in the function, it probably
> > also leaves the variables in the .data section, wasting space.
> 
> Nope, it fixes that too, just like it omits any other static 
> object that's not used after other optimizations.

This depends on the gcc version and -f options, particularly 'unit at
a time'. It's default with -O2 and higher (maybe even -O1) in recent
gcc releases but this increases the amount of memory required to
compile by (typically) 2-5x and it's ugly to rely on it.

> > In any case I don't like writing overly verbose code and relying on the
> > compiler to thin it down when one could just write it simpler to begin
> > with.
> 
> I can change it to #define if you like.

It would make me and my gcc happy.

Rich