This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C compile time


> 
> > Note that I consider not having unit-at-a-time for C++ for 3.4 as a
> > showstopper as it is possibly the only way to get sane inlining and
> > such sane performance out of scientific C++ codes like POOMA.
> 
> Sorry -- we'll not hold 3.4 for this functionality.  It is likely to
> introduce new issues, and if it's not ready we'll hold off.
> 
> I agree that it's very desirable, but we've never had it until now, and
> we've always had a compiler people wanted to use for many projects.

I still hope to have something in the 3.4 timeframe, but any help is
appreciated :)
Today I started again from my original patch and I've cleaned up the way
functions are deferred, so now I deffer all functions to the end of
file, where I do finalize them and the new functions are finalized
immediately so at least I avoid duplication in between cgraphunit and
decl2.c's idea of deprecating functions.

Still I would like to understand when the given function can be
finalized - if I do that and turn cgraphunit code to deal with
non-unit-at-a-time mode as well, I can get non-unit-at-a-time mode to
expand function as soon as it is clear that it is needed and it is ready
saving some memory relative to current scheme that deffers always to the
end of compilation.

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]