[LLVMdev] Changing the design of GlobalAliases to represent what is actually possible in object files.

[Rafael Espíndola]

> I agree that this accurately summarizes both (1) what’s expressible in
> current object file formats and (2) what we’re likely to want to need from
> global aliases.
>
>> The tool we have in llvm for creating these extra labels is the GlobalAlias.
>>
>> One way of representing the above uses is to be explicit: a label is
>> created with a specific value or at an offset from another.
>
> Also important: in this model, the label has its own LLVM type, which is
> permitted to differ from the LLVM type of the aliasee (if present).
>
> I will note that this model does require absolute symbols to be literal values.
> That eliminates a lot of things that are at least theoretically useful.
>
> For example, it would not be possible to define an absolute symbol to be
> the offset between two symbols.  In some restricted circumstances —
> if both symbols are global variables in the same section and defined
> in the same translation unit — this could be worked around.
>
> But I’ll gladly admit that I don’t have a use case in mind for that feature.
> Absolute symbols are useful, and storing offsets between symbols into
> global memory is useful, but I don’t know why you’d combine them.

That is funny. I, on the other hand, think that this is the best
argument I have seen for keeping aliases pointing to ConstantExpr so
far.

While labels and relocations are very different things at the object
level, llvm is not currently in a position to know when a relocation
is needed or not. I would like for that not to be the case, but that
is a far bigger change. It also points out that an expression being a
valid label definition or not can change in a way that is hard to see
during the change itself: We can have an arbitrarily nested expression
that goes from evaluatable to requiring a relocation when the section
of a global object is changed. That in turn puts the validity check in
the verifier, even we constraint ConstantExprs.

In other words, another possible representation would be

* GlobalsAlias point to ConstantExpr
* The expression is completely unconstrained in the current
implementation of ConstantExpr.
* There is no notion of an aliased symbol. Things like detecting
cycles go from "A == A->getAliasedSymbol()" to
"A->getAliasee().uses(A)", but even that seems questionable outside of
special case like clang that knows the types of alias it creates.

This would greatly diminish our ability to report invalid uses, since
the first thing to noticed they are invalid is MC. It would also
require the alias to weak alias problem to be handled directly in the
IR linker. In here we would have to approximate: do our best to
evaluate it, but if the expression still has discarded globals, error.

In other words, painful but reasonable. I will have to look at the
code to see how painful it is to generalize every user of the "aliased
symbol" to work with an arbitrary expression. I will experiment with
it tomorrow and report.

> I don’t think I accept that ConstantExpr just means “relocation” in IR,
> either in principal or as a description of reality.  A constant used only as
> an instruction operand is definitely not limited to what’s expressible
> with relocations.

Yes. I know there are disagreements about ConstantExpr, but think we
all agree that they are *at least* as general as any relocation we
want to represent.

>> It also makes general IR operation like rauw easier to reason about.
>> Since ConstantExpr are uniqued, they have a more complex replace
>> implementation where they have to be replaced one level at a time. We
>> would have to wait until the replacement reaches the GlobalAlias to
>> see if it still is one of the ConstanExprs that happen to be just a
>> label and an offset, and if it is not we would have not easy way of
>> knowing what went wrong.
>
> Is this not still true under the global-and-offset model?  If you replace
> the target of a GlobalAlias with a ConstantExpr, RAUW will have to
> evaluate the expression down to a global and an offset in exactly the
> way that you’re worried about the backend having to do.  Except,
> of course, RAUW has to worry about working with a module that
> lacks data layout.

But in here RAUW is seeing the actual replacement. It is seeing the
GlobalObject that is directly used by a GlobalAlias being replaced
with an expression. If the alias points to a Constant, it is seeing
the result of a perfectly valid run of replaceUsesOfWithOnConstant
which may or may not be a valid aliasee.

Cheers,
Rafael