This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names
Bill Maddox wrote:
To move toward a language-independent IR, however, it is good hygiene
to strip this stuff so we aren't fooling ourselves.
Yes, the question is just when to do the stripping. My point is that
stripping early implies that the FE must generate everything you might
ever want early and that is quite possibly expensive.
I'm not terribly
comfortable with aggressively cleaning the tree in free_lang_specifics
until we've clarified a GIMPLE type system and a plan for adjusting
early-generated debug info to reflect middle-end optimization.
That's kinda what I think too. I'm we're approaching this as "throw
everything away, see what breaks, fix it" and that seems like a risky
method for such a major change. If we go down this path and don't like
it, it will be hard to back out.
The only thing actually required for LTO to work is that we not use FE
callbacks to interpret the intermediate. There's no inherent reason all
the FE-specific data has to be freed. So, we do have to mangle names
before we write out LTO information (since we won't have an FE to mangle
them for us later), but we don't necessarily have to do that at the
point of GIMPLE-fication.
In fact, if we have big pieces of tree that are swapped out (e.g., PCH),
running around freeing bits of them is probably going to slow things
down, rather than speed them up. In the case of PCH, we're going to be
touching disk. Maybe we should just not write the data out to the LTO
file, rather than trying to free it early. If you like, have a
free-it-early mode for error-checking (to make sure that we aren't
relying on that data) in the same way that we have an always-collect
mode for GC (to make sure we're not depending on things not being
collected).
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713