[LLVMdev] GHC, aliases, and LLVM HEAD

Ben Gamari bgamari.foss at gmail.com
Wed Jul 23 09:06:17 PDT 2014


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>


More information about the llvm-dev mailing list