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

[John McCall]

On May 22, 2014, at 5:13 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> Bringing the discussion to llvmddv.

Thanks for doing this.

> For the purposed of this discussion, object files can be thought as
> having just a few thing we care about: data, labels and relocations.
> 
> Data is what at llvm ir would be just the contents of variables or functions.
> 
> Relocations are utilities to compute the data at link time when it is
> not possible to do so earlier. For example, to compute a pcrel
> relocation we need to know the offset of a given symbol to the current
> position.
> 
> Relocations at the llvm IR are represented with ConstantExpr. There is
> a point to be made that that representation could be better, but I
> thing that is not too important for this discussion. Whatever we turn
> ConstantExpr into it will always have to be able to represent the
> relocations we want to create.
> 
> Now for the main part of this proposal: The labels.
> 
> Some labels are implicitly created for other llvm constructs. A
> Function or a GlobalVariable will have one for example.
> 
> But labels at the object files are not constrained to point to what at
> the LLVM level is a Function or a GlobalVariable. We need a way to ask
> for other labels. We need to
> 
> * Be able to create labels with an absolute value.
> * Be able to create labels inside a GlobalVarible or pointing to the
> start of a GlobalVariable or Function.

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.

> Another way of representing it is with a ConstantExpr, since those two
> cases are a subset of what a ConstantExpr can represent.
> 
> My preference is for having an explicit offset that is just an
> integer. Using an ConstantExpr seems conflation of two different
> things: labels and relocations. The fact that some relocations are as
> simple as a label plus an offset seems incidental.

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.

> From an implementation perspective having a representation that uses
> just a GlobalObject and an offset seems beneficial too. Any attempt to
> create a non representable label (GlobalAlias) will fail immediately,
> instead of leaving the IR in a state that will fail down the line.
> 
> 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.

John.