[cfe-commits] r99012 - in /cfe/trunk: lib/CodeGen/CGCXX.cpp lib/CodeGen/CGDebugInfo.cpp lib/CodeGen/CGDecl.cpp lib/CodeGen/CodeGenModule.cpp lib/CodeGen/CodeGenModule.h lib/CodeGen/Mangle.h test/CodeGenCXX/attr.cpp
Chris Lattner
clattner at apple.com
Tue Mar 23 15:45:44 PDT 2010
On Mar 23, 2010, at 3:24 PM, John McCall wrote:
>
> On Mar 23, 2010, at 2:54 PM, Chris Lattner wrote:
>
>>
>> On Mar 19, 2010, at 4:29 PM, John McCall wrote:
>>
>>> Author: rjmccall
>>> Date: Fri Mar 19 18:29:14 2010
>>> New Revision: 99012
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=99012&view=rev
>>> Log:
>>> Change CodeGenModule to rely on the Module's symbol table instead of
>>> shadowing it in the GlobalDeclMap. Eliminates the string-uniquing
>>> requirement for mangled names, which should help C++ codegen times a little.
>>> Forces us to do string lookups instead of pointer lookups, which might hurt
>>> codegen times a little across the board. We'll see how it plays out.
>>>
>>> Removing the string-uniquing requirement implicitly fixes any bugs like
>>> PR6635 which arose from the fact that we had multiple uniquing tables for
>>> different kinds of identifiers.
>>
>> Hi John,
>>
>> Why not get the best of both worlds and map from StringMapEntry*'s instead of the string itself? The stringmap entry can be obtained from the LLVM Module, no?
>
> Not as far as I can tell; you can ask a module for its ValueSymbolTable, but you can't ask a ValueSymbolTable for its StringMap<Value*> or any other private data. It looks like I could reinterpret_cast to StringMap, but I suspect you're not suggesting that. :) I could certainly expand the ValueSymbolTable API to give direct access to the StringMap; that breaks encapsulation but otherwise isn't too horrible.
Call Value::getName! So obvious ;-)
-Chris
More information about the cfe-commits
mailing list