This is the mail archive of the gcc-patches@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]

Re: aliasing warnings [patch]


>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    Joe> My crude *guess* would be that the extra pointer slot
    Joe> wouldn't matter that much, as long as we continue the current
    Joe> policy of only using trees for statements, not whole
    Joe> functions.  It would matter more if we keep trees around for
    Joe> whole functions.

We do.  The C++ front-end now keeps around trees for whole functions;
that's been how I've been busy breaking the tree lately.  Right now,
we don't even throw the bodies away at the end of the function, but we
could, and probably should.  I'll do this reasonably shortly; one the
rest of the function-at-a-time stuff is done.

In the not-too-distant future, I'd like us to parse the entire
translation unit first, and then go back and generate RTL for just
those functions that are actually needed.  This will reduce the time
for the compile-edit-debug cycle; we won't waste time generating RTL
when a later error is going to prevent compilation.  Plus, we can do
inlining on trees, and such.

The last time I profiled some template-heavy C++ code with -O2, I saw
a ton of memory usage from copying declarations from inlined functions
into the functions that contain them.  We do that even when not -g.
Part of the problem there is that when a calls b calls c, we inline c
into b, even when we only want to output a.  That means c's
declarations are copied twice, rather than just once.  We should fix
that.

Bottom line: trees are going to be an increasingly high part of our
memory budget; we want to be careful about increasing their size.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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