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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Thu May 22 17:13:25 PDT 2014


Bringing the discussion to llvmdev.

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.

Note that it is still just a label. No relocations are involved.

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.

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.

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

Cheers,
Rafael



More information about the llvm-dev mailing list