llvm dev - Jul 2014 - [LLVMdev] GHC, aliases, and LLVM HEAD

Reid Kleckner <rnk at google.com> writes:
> On Tue, Jun 3, 2014 at 1:29 PM, Rafael Espíndola <rafael.espindola at
gmail.com
>> wrote:
>
>> > It looks fairly likely llvm will accept arbitrary expressions as
>> > aliasees again (see thread on llvmdev), but the restrictions
inherent
>> > from what alias are at the object level will remain, just be
reworded
>> > a bit. For example, we will have something along the lines of
"the
>> > aliasee expression cannot contain an undefined GlobalValue".
>>
>> And this is in: r210062.
>>
>> Let us know how it looks from GHC's point of view.
>
>
> I think we might be able to relax our restrictions against aliases
> referring to declarations if the alias is private.  If the alias is
> private, then the label never appears in the object file.  The alias is
> merely a Constant with an internal name.  What do you think?
Any word on this? As far as I can tell we are stuck on the GHC side
until we can alias declarations due to the existence of untyped external
references in the C-- representation.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140720/9e39156e/attachment.sig>

> Any word on this? As far as I can tell we are stuck on the GHC side
> until we can alias declarations due to the existence of untyped external
> references in the C-- representation.
I still have the same objections to having alias to declarations when
they are not supported in the object file. Since they are not
supported in the object file, they must be removed somewhere along the
way and it is not clear the burden should be in the LLVM to Obj
transition instead of in the transition from c-- to llvm.

It is also still not clear why you need aliases at all. LLVM has
declarations and bitcasts, so like c-- it is not type safe, but unlike
c-- (from your description) casts are needed.

Cheers,
Rafael

Rafael Espíndola <rafael.espindola at gmail.com> writes:
>> Any word on this? As far as I can tell we are stuck on the GHC side
>> until we can alias declarations due to the existence of untyped
external
>> references in the C-- representation.
>
> I still have the same objections to having alias to declarations when
> they are not supported in the object file. Since they are not
> supported in the object file, they must be removed somewhere along the
> way and it is not clear the burden should be in the LLVM to Obj
> transition instead of in the transition from c-- to llvm.
>
> It is also still not clear why you need aliases at all. LLVM has
> declarations and bitcasts, so like c-- it is not type safe, but unlike
> c-- (from your description) casts are needed.
>
The aliases are necessary because LLVM makes us provide the type of the
value we are trying to cast: we can't construct a `bitcast` expression
for a symbol until we know its type. For this reason, we need to create
aliases hiding the true types of our definitions, allowing us to assume
some common type (e.g. `i8*`). As you said, these aliases are just
bitcasts; they are needed, however, because they can be created at the
point when we know the type of the symbol.

Over the weekend I reworked [1] the handling of aliases in the LLVM
backend, moving them from the point of usage to the compilation unit the
symbol is defined within. As all aliases now point to definitions this
avoids upsetting LLVM. The code needs some cleaning up but the approach
seems sound so it seems fair to say that we won't be needing aliases to
declarations afterall.

At this point the last(?) LLVM feature that we lack is symbol
offsets/prefix data. As has been discussed earlier [2] the current
realization of these concepts are quite suboptimal (and arguably most
other) for our usecase(s). Reid's proposal on this matter sounded quite
promising.

- Ben


[1] https://github.com/bgamari/ghc/compare/llvm-3.5-new
[2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073260.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140723/c4ef9a9e/attachment.sig>