[LLVMdev] inefficiencies in ConstantUniqueMap ?

Chris Lattner clattner at apple.com
Thu Jun 30 13:26:15 PDT 2011


On Jun 30, 2011, at 5:38 AM, Jay Foad wrote:
> In case anyone's interested, here's my work-in-progress patch for
> clang. (Note that it's against a slightly old clang tree, because the
> llvm type-system-rewrite branch hasn't had a merge from trunk
> recently; and you also need the attached llvm patchlet to make it all
> build.)
> I'm not 100% satisfied with it but it is good enough to build sqlite3
> from the test suite.

Wow, that's great!  I'm using my few spare cycles to try to finish up the linker and bitcode reader, I really appreciate you working on this.  I landed your Constants.h helper function.  I'll update the branch to mainline if I can figure out how to get SVN to do what I want :)

>> 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.
> 
> I now get:
> 
> %struct.T = type { i8* }
> @t = global %struct.T { i8* bitcast (void ()* @f to i8*) }, align 8
> declare void @f()
> 
> (I lowered the incomplete function type all the way to void, instead
> of to void(), only because that made it simpler for
> CodeGenModule::GetOrCreateLLVMFunction() to tell the difference
> between a proper function type and a placeholder type. There's
> probably a better way of doing this.)

This makes perfect sense to me.

>> Basically, if we "need" a type and don't have it, just lower it directly to void instead of 'opaque'.
> 
> I'm doing this for:
> 
> - incomplete non-fixed enum types
> - functions types whose argument or return types are incomplete
> (because in that case the ABI stuff can't work out how parameters are
> going to be passed/returned, so you can't get a proper LLVM type for
> the function)

Yep, makes sense.

>>  This will lead to some more bitcasts downstream, but we already have that, they get resolved if f is ever implemented.
> 
> I don't have a good understanding of which bits of Clang's codegen are
> prepared to insert bitcasts like this; but it seems to work well
> enough to build sqlite3!

My bet is that this is really really close.

-Chris




More information about the llvm-dev mailing list