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

Loren Merritt lorenm
Thu Feb 21 17:22:20 CET 2008


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?

> 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.

> 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.

--Loren Merritt




More information about the ffmpeg-cvslog mailing list