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
On Mon, May 17, 2010 at 3:43 AM, David Terei <davidterei at gmail.com>
wrote:> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sec.c
Type: application/octet-stream
Size: 1093 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100517/191ea903/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sec.sh
Type: application/x-sh
Size: 393 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100517/191ea903/attachment.sh>