[LLVMdev] inefficiencies in ConstantUniqueMap ?

Chris Lattner clattner at apple.com
Mon Jun 27 10:58:42 PDT 2011


On Jun 25, 2011, at 11:59 AM, Jay Foad wrote:

> On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote:
>>> 3. Clang/dragonegg need to adapt to the new API (help appreciated!)
>> 
>> what needs to be done exactly?
> 
> Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt
> 
> As I understand it, PATypeHolder, OpaqueType and the Module's
> TypeSymbolTable are gone. Instead, StructTypes can optionally be
> named, and if they are then:
> 
> - they use name equivalence instead of structural equivalence.
> - you can create them without any fields, and then add the fields
> later when the struct is complete.

Right, exactly.  The major impact is that the various AbstractTypeUser-related classes (including OpaqueType) are gone, and the StructType interface is richer:
http://llvm.org/viewvc/llvm-project/llvm/branches/type-system-rewrite/include/llvm/DerivedTypes.h?revision=133420&view=markup

> I've played with the Clang bits of this. The biggest problem I've
> found is that Clang uses LLVM's type resolution not just for
> forward-declared structs/classes/unions, which convert
> straightforwardly to the new system, but also for forward-declared
> enums, which don't.

I haven't started looking at this at all yet, but it seems that we could use a similar example for forward declared structs whose bodies are needed.  Clang currently codegen's this:

struct S;
struct S f(void);
struct T { struct S (*f)(void); };
struct T t = {f};

into:

%0 = type opaque
%struct.T = type { %0* }

@t = global %struct.T { %0* bitcast (void ()* @f to %0*) }, align 8

for example.  Instead of doing that, we can/should just codegen it to:

%struct.T = type { void ()* }

@t = global %struct.T { void ()* @f }, align 8

directly.  Basically, if we "need" a type and don't have it, just lower it directly to void instead of 'opaque'.  This will lead to some more bitcasts downstream, but we already have that, they get resolved if f is ever implemented.

> Also, varargs forms of StructType::createNamed() and
> StructType::setBody() would save a lot of mindless churn in the Clang
> source code.

Please feel free to add it to the branch!

-Chris



More information about the llvm-dev mailing list