llvm dev - May 2014 - [LLVMdev] Changing the design of GlobalAliases to represent what is actually possible in object files.

> 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

On Thu, May 22, 2014 at 7:14 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
>
> > 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.
>
IMO if we want to support defining symbols at absolute addresses, we should
add a separate construct for this.  So far everyone has gotten by with
linker flags and scripts, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140523/fb9a3d2b/attachment.html>

>> > 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.
>
>
> IMO if we want to support defining symbols at absolute addresses, we should
> add a separate construct for this.  So far everyone has gotten by with
> linker flags and scripts, though.
Well, if we support an arbitrary ConstantExtpr it is hard not to
support absolute symbols.

Attached is a work in progress on trying to see how hard it would be
to implement support for arbitrary ConstantExpr.  I is fairly
incomplete. In particular, the linker need to be updated. But it can
already codegen things like

------------------------------------------------------------------------------
@foo = global i32 42
@test1 = alias getelementptr(i32 *@foo, i32 1)

; absolute: 42
@test2 = alias inttoptr(i32 42 to i32*)

@test3 = alias inttoptr(i64 ptrtoint (i32* @foo to i64) to i32*)

; absolute: 4
@test4 = alias inttoptr(i64 sub (i64 ptrtoint (i32* @test1 to i64),
                                 i64 ptrtoint (i32* @foo to i64)) to i32*)
------------------------------------------------------------------------------------------

I have to run now, but will try to get something that I can send for
proper code review during the weekend.

Judging from what I have seen so far I would be OK with

* Supporting only symbol + offset and representing that directly.
* Supporting "any" ConstantExpr.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 33307 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140523/98dcaead/attachment.obj>

I'm not there yet, but at some point I'm going to need the notion of a
global callable function like symbol that's resolved at runtime. I've
not given it much thought but I may need a new callable entity here
(this is for the gnu ifunc stuff).

Don't even know if this fits into the discussion, but since we were
talking about weird symbols...

-eric

On Fri, May 23, 2014 at 1:26 PM, Reid Kleckner <rnk at google.com>
wrote:
> On Thu, May 22, 2014 at 7:14 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> > 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.
>
>
> IMO if we want to support defining symbols at absolute addresses, we should
> add a separate construct for this.  So far everyone has gotten by with
> linker flags and scripts, though.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>