[llvm-commits] [llvm-gcc-4.2] r93727 - in /llvm-gcc-4.2/trunk/gcc: llvm-convert.cpp llvm-debug.cpp llvm-debug.h llvm-internal.h

[Chris Lattner]

On Jan 18, 2010, at 5:18 PM, Stuart Hastings wrote:

> 
> On Jan 18, 2010, at 1:02 PM, Chris Lattner wrote:
> 
>> 
>> On Jan 18, 2010, at 9:19 AM, Stuart Hastings wrote:
>> 
>>> Author: stuart
>>> Date: Mon Jan 18 11:19:18 2010
>>> New Revision: 93727
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=93727&view=rev
>>> Log:
>>> Radar 7387470
>>> Support for lexical blocks in DWARF.
>>> 
>>> Declare local variables inside their lexical blocks.  This required a
>>> change to the order of declaration of local variables, exposing many
>>> latent bugs in the GCC front-end (hopefully all previously addressed).
>>> Note that variables must be emitted in the same order with and without
>>> debug output for consistency.
>> 
>> hi Stuart,
>> 
>> This does a lot of work even when debug info is not turned on.  Is it possible to avoid doing anything when it isn't enabled?
> 
> O.K., I've thought about this, and here's a list of New Work(tm) that slows down compilation even when Debug is off:
> 
> ---------------------------------------
> In StartFunctionBody(), we walk GCCs BLOCK tree and collect "block_declared_vars", a SmallPtrSet of all variables hanging from any lexical BLOCK.
> Instead of emitting every variable on GCCs unexpanded_var_list, we only emit variables that are not in our new "block_declared_vars" set.
> 
> In switchLexicalBlock(), we maintain "SeenBlocks," a SmallPtrSet of BLOCKs that we have previously processed.
> Whenever we encounter a new BLOCK, we add it to "SeenBlocks" and emit the variables hanging from it.
> ---------------------------------------
> 
> I think the above is the minimum necessary for consistent code generation when debug is on or off; if we emit variable declarations into LLVM in a different order, I expect users would see a profound change in the register allocation, and thus the generated code.  Nevertheless, I've been wrong before (gasp! :-), and I'd be happy to rewrite something if you see an opportunity.  Frankly, I was more concerned about getting a correct (and non-segfaulting) result than an optimal one, and I may have done something dumb.
> 
> I recall adding some searching to the GCC front-end in a few spots (calls to debug_find_var_in_block_tree() in r93387 and r93394), but I expect these will rarely be executed.
> 
> If debug is currently off, we already skip the pushing and popping of lexical contexts.  However, I expect that most non-C++ code has very simple lexical scoping (e.g. one function-level lexical scope), and I doubt there's much work saved here.
> 
> This suggests an idea: it might be feasible to optimize the (common?) case of a function with exactly one lexical scope.  This would save the BLOCK walk in llvm-convert.cpp:setLexicalBlockDepths(), and the creation of one SmallPtrSet.
> 
> I don't think we can fall back to "emitting every local variable on the unexpanded_vars_list" as we used to do, because I think this would change the order of declaration of variables when debug is on.
> 
> Hm.  I suppose I should rename "block_declared_vars" into "BlockDeclaredVars" for conformity.

Ok, if you've thought about it and this seems a reasonable thing to do, then it sounds fine to me.  Please make sure this doesn't impact -O0 -g compile time (i.e. with debug info turned on) very much as well though.  

-Chris