[LLVMdev] LLVM IR Type System Rewrite

[Frits van Bommel]

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? 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.

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). Which raises the question of what casts
to allow:
a) between struct types that are structurally identical (which leads
us back to graph isomorphism, though with only two types at a time to
worry about), or
b) between struct types with the same size (which might not be
knowable without target data), or
c) some other criterium I haven't thought of yet.

Merging pre-existing struct types (i.e. types in the source module)
would likely be problematic as well unless something like a "use list"
of types is still maintained. In other words, you still wouldn't be
able to get rid of PATypeHolder and friends.
Also, this wouldn't preserve the names of some of the struct types,
which you mentioned as a design goal.

Is there some other solution for this I'm not seeing, or is one of the
ones I mentioned less problematic than it appears at first glance?