[PATCH] IR: Add COMDATs to the IR

[Rafael Espíndola]

> I would prefer to make sure we get this design right. Why do you need
> the symbol table? A comdat is just a name. The value symbol table is
> expecting to handle actual Values. It has logic for renaming for
> example, which should never be used for comdat. It looks for a comdat
> what we want is really just a StringMap (if that much).
>
> At a very fundamental level a comdat is not a value. It can never be
> passed as an operand to an operation.
>
> I listed the cases where it looks like we will be accessing comdats to
> show  that we are not getting a lot of value from a design that forces
> a comdat into a class hierarchy it doesn't belong to.
>
> A comdat is really just a property of a global object, just like the
> section or the alignment. Finding all the objects that are in a comdat
> is a similar operation to finding all the objects that are in a
> section or have a given alignment.

Nick and I discussed this on IRC a bit. It seems the main argument for
making a comdat a value is convenience, it gets written to .bc in the
same way other Values get written. It also avoids adding space to a
GlobalObject when there is no comdat.

The fundamental problem of a Comdat not being a Value in the semantic
sense can be mitigated by having a special type that is used for
nothing else. That way the llvm type system would avoid the oddity
that is present in the c++ level.

It still seems we would be getting more than what we need from making
it a Value. The name handling is incredibly complicated to support
renaming and collision. It seems that it is better if comdats are
immutable and we phrase operations like "change all objects with
comdat 'foo' to have comdat 'bar'" instead of "rename comdat 'foo' to
comdat 'bar".

I will apply this patch locally and play with it a bit to get a better
feel of the tradeoff.

Cheers,
Rafael