[PATCH] IR: Add COMDATs to the IR

[Rafael Espíndola]

>> Now that I think of it, a comdat having Uses is probably undesirable
>> in itself. Some of the potential issues that come to mind:
>>
>> * RAUW should not change what is in a comdat.
>
>
> I don't follow. Why shouldn't it?

Consider a comdat with two functions, f and g. Say that f has many
uses and there is nothing interesting to do with it. Now g is always
called with a fixed value, and we can specialize it. The code that is
doing it creates an internal g_specialized, and calls RAUW. If would
not be correct for the call to change the condat to having f and
g_specialized. Since g_specialize is internal, we would get a link
error if the linker decided to keep the comdat from this translation
unit.

>>
>> * Logic for checking if something has only one use should also not be
>> affected by comdats.
>
>
> The GV uses the comdat group, not the other way around?

That would be fine, if we need that.

>> * Other code walking all uses probably be surprised to find a comdat.
>
>
> Well sure, it's a new IR extension. This happens to not come up in practice
> because you need to iterate the list of comdats in the module, or else grab
> a section and ask it for its comdat group. You could get there by accident
> (I think the section stores its comdat group as an operand) but that never
> comes up.

This comment is also assuming that the GV uses the comdat, right? The
issue would be the other way around, but I think I misread the code,
for some reason it looked like the comdat was using the GV.

> Sure, but why? You're proposing that we reimplement functionality from Value
> because we don't need part of the functionality in Value. We want the value
> naming and its symbol table, and I'm pretty sure we want the use lists or
> equivalent functionality. We don't want a Type, but we can choose "i8" and
> move on?

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.

Cheers,
Rafael