GHC's LLVM Backend

Hi All,

The Glasgow Haskell compiler has recently become an external user of
LLVM. You can read about it here:

http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html

If you have any comments, questions or perhaps even advice on solving
some of the issues that need to be fixed in the backend going forward
then please reply to this email.

Cheers,
David

Great stuff!

Re tables next to code -- I think this can be done in GNU C without
the evil post-processing of assembly code. The idea is to put info
table and code into the same section, say .ghc.text.<funcname>, and
merge these sections into .text.
I can't get GCC to put data and code into the same section and I'm not
sure it guarantees it's relative ordering. To work around this we can
put info table into .ghc.<funcname>.0 section and code into
.ghc.<funcname>.1 then make linker sort by name and merge these
sections. This is a fairly standard practice supported at least by
Microsoft linker (with a slightly different naming convention) and gnu
ld (via a custom linker script).
Attached is a toy proof-of-concept example of using this technique
that should work with gcc+gnu ld on many platforms.

This approach can be used with LLVM directly (it already supports
required GNU extensions), delegating the final merging to system
linker, or a similar approach can be developed in LLVM. There are a
few options:

- The simplest thing is to place both table and code into the same
section and guarantee that ordering of objects belonging to the same
section is preserved by all transformations.

- Failing that we'll need a way to mark several objects as being
output together in a particular order. This cannot be done via
metadata (because dropping this association will break the code) so
this has to be done via a special global, a-la @llvm.used.

Another thing is that ideally a function should be used by it's info
table instead of forced used via @llvm.used.

Eugene

sec.c (1.07 KB)

sec.sh (393 Bytes)