[LLVMdev] LLVM IR Type System Rewrite

[Chris Lattner]

On Feb 27, 2011, at 9:48 AM, Rafael Ávila de Espíndola wrote:
>> Comments welcome!
> 
> Having fewer types makes the job of the passes easier. Right now we 
> maintain a small number of types as we go, which is expensive. In the 
> proposed change, would it still be legal to write a type merging pass? 
> For example, lets say we have
> 
>   %Foo = type { i32 }
>   %Bar = type { i32 }
>   @a = unnamed_addr constant %Foo { i32 42 }
>   @a = unnamed_addr constant %Bar { i32 42 }
> 
> The typemerge pass could turn this into
> 
>   @a = unnamed_addr constant {i32} { i32 42 }
>   @b = unnamed_addr constant {i32} { i32 42 }
> 
> And constmerge will then merge them as it does today.

I don't see this as requiring a type merging pass.  A better way to handle this (IMO) would be to generalize constant merging to handle bit identities, which would allow it to merge things like:

@a = unnamed constant i32 0
@b = unnamed constant float 0.0

This can be done today, and then the type system change won't affect constant merging.

> Another comment is that getting anonymous types would still be a bit 
> expensive. Can we get away with just Named types (including Unnamed) and 
> trusting typemerge to do its job?

Getting an anonymous type should be the same cost as getting a struct type today: just look it up in a (redesigned) uniquing table.  However, as I just mentioned to Jan, it might be better to just drop the concept of anonymous types entirely.  This would simplify the model and is even closer to what we have today.

-Chris