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

[Michael Niedermayer]

On Fri, Feb 22, 2008 at 08:57:39AM -0500, Rich Felker wrote:
> On Fri, Feb 22, 2008 at 02:42:02PM +0100, Michael Niedermayer wrote:
> > On Fri, Feb 22, 2008 at 12:44:13AM -0500, Rich Felker wrote:
> > > On Thu, Feb 21, 2008 at 10:35:53PM -0700, Loren Merritt wrote:
> > > > On Thu, 21 Feb 2008, Rich Felker wrote:
> > > > >
> > > > > 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.
> > > > 
> > > > It doesn't even have to be declared const.
> > > > "static unsigned long pb_7f = 0x7f7f7f7f7f7f7f7fUL" works too: gcc sees 
> > > > that it is never assigned to and thus is in fact constant. (assuming unit 
> > > > at a time, of course)
> > > 
> > > If I someday switch to gcc 4, -fno-unit-at-a-time is probably the only
> > > hope of building with <= 128 megs of ram. I'd rather not have
> > > gratuitous dependencies on unit-at-a-time for optimal code when it's
> > > trivial to write the optimal version directly.
> > 
> > I dont see why a properly written compiler would need 128mb ram to figure
> > out which static variables arent written to. grep is well capable of doing
> > that ...
> 
> The issue is that gcc insists on building a syntax tree and all its
> optimization structures for the ENTIRE file in order to be able to do
> optimizations like this. While your claim about grep is morally true,
> it leaves out the fact that in order to perform this optimization for
> all variables, you'd need to parse and identify all static variables,
> then perform this grep-like checking for each one. And don't forget
> about the preprocessor =) which can make grepping hard.

The preprocessed source of one file is not 128m, gccs data structures
must be heavily bloated if it needs that much.

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080222/7cd7c10d/attachment.pgp>