llvm dev - Jun 2011 - [LLVMdev] inefficiencies in ConstantUniqueMap ?

Hi Chris,
> 3. Clang/dragonegg need to adapt to the new API (help appreciated!)
what needs to be done exactly?

Ciao, Duncan.

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.

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.

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

Jay.

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

Hi Jay,
> 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.
I find this distinction between structs with names and structs without
names strange.  Why is a name relevant to anything?  If you can add fields
to a struct with a name why not to a struct without a name?

Ciao, Duncan.