[LLVMdev] LLVM IR Type System Rewrite

[Chris Lattner]

On Feb 26, 2011, at 2:53 PM, Frits van Bommel wrote:

> On Sat, Feb 26, 2011 at 10:25 PM, Chris Lattner <clattner at apple.com> wrote:
>> Several people have been proding me to write up my thoughts on how to fix the IR  type system for LLVM 3.0.  Here are some (fairly stream of conscious) thoughts on the matter:
>> http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt
>> 
>> Comments welcome!
> 
> So struct types would unique by name. How important would it be for
> the linker to preserve those names?

Not at all.  The linker will do a best approximation, but it will autorename on unresolvable conflicts, just like we do for internal functions when linking.

> Because I can think of a few
> examples where it could be problematic. For instance, if you want to
> link
> 
>  %Foo = type { i32 }
>  %Bar = type { i32 }
> 
>  %myFoo = global %Foo
>  declare void @useBar(%Bar* %arg)
>  ; ...
> 
> with
> 
>  %Baz = type { i32 }
> 
>  %myFoo = global %Baz
>  declare void @useBar(%Baz* %par)
>  ; ...
> 
> then AFAICS the linker would either have to insert some casts (ugly)
> or it would need to somehow recognize that %Baz, %Foo *and* %Bar need
> to be merged into one type.

In the system I'm envisioning, you'd get a bitcast.  The same thing happens today when linking modules that contain things like:

a.ll:
declare void @foo(i32)
... uses of @foo ...

b.ll:
define void @foo(i8*) ...

> Inserting casts would mean that a way to cast between different struct
> types is needed (for instance, bitcast could be extended to allow
> casting between struct types).

We already have this logic.  The function itself is cast and instcombine attempts to resolve conflicts where reasonable.  There is no IR extension needed for this.

-Chris