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

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

> Judging from what I have seen so far I would be OK with
>
> * Supporting only symbol + offset and representing that directly.
> * Supporting "any" ConstantExpr.
Most of the uses of getAliasee were (or are) bugs and missing
features. With those out of the way, the tradeoff of the above options
becomes having the ability to represent any symbol value that the
assembler can at the cost of far weaker checking for the expressions
defining the global alias.

I reported the most annoying IR X object file mismatch as pr19848.
Since it is present in both representation we can handle it after
this.

The attached patches are on top of the patch I emailed for pr19844.

Is everyone sufficiently satisfied with this direction? Can I resend
the patches to llvm-commits  and cfe-commits?

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.patch
Type: application/octet-stream
Size: 49888 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/f397edc4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.patch
Type: application/octet-stream
Size: 13278 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/f397edc4/attachment-0001.obj>

On May 26, 2014, at 3:25 PM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>> Judging from what I have seen so far I would be OK with
>> 
>> * Supporting only symbol + offset and representing that directly.
>> * Supporting "any" ConstantExpr.
> 
> Most of the uses of getAliasee were (or are) bugs and missing
> features. With those out of the way, the tradeoff of the above options
> becomes having the ability to represent any symbol value that the
> assembler can at the cost of far weaker checking for the expressions
> defining the global alias.
> 
> I reported the most annoying IR X object file mismatch as pr19848.
> Since it is present in both representation we can handle it after
> this.
> 
> The attached patches are on top of the patch I emailed for pr19844.
> 
> Is everyone sufficiently satisfied with this direction? Can I resend
> the patches to llvm-commits  and cfe-commits?
This direction looks great to me.  Thank you, Rafael!

Not a full review, but typo:

+Since aliasess are only

John.