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 [EMAIL PROTECTED] (650) 331-3385 x713
