[LLVMdev] LLVM GHC Backend: Tables Next To Code

[Sergiu Ivanov]

Hello everyone,

On behalf of GHC hackers, I would like to discuss the possibility of
having a proper implementation of the tables-next-to-code optimisation
in LLVM.

Currently, the object code produced by all three GHC backends follows
the convention that the table with the metadata of a closure is
located immediately before the code of the closure.  This makes it
possible to get to both the code and the metadata after a single
pointer resolution operation.  This, obviously, requires certain
ordering of data and text in the object code.  Since LLVM does not
make it possible to explicitly control the placement of data and code,
the necessary ordering is currently achieved by injecting GNU
Assembler subsections on platforms supported by GNU Assembler.  Mac
assembler, however, does not support this feature, so the resulting
object code is post-processed directly.

It would be desirable that LLVM offered some control over the ordering
of text and data sections in the code.  In particular, David Terei
suggests one of the following [0]:

1. Add a special variable "llvm.order" of an array type.  It will list
   function names and global pointers in the order in which they
   should appear in the resulting object code.  This basically
   corresponds to the "fno-toplevel-reorder" option in GCC.

2. Add support for attaching a global variable to a function.  In this
   way one could be able to specify a that a global variable should
   appear before the corresponding function in the object code.

An example of a possible implementation of (2) has been recently
suggested by Gabor Greif.  He proposes adding a "placebefore"
attribute to global variables (or, similarly, a "placeafter" attribute
for functions).  The corresponding example is:

  @foo_D = common global %struct.Descr zeroinitializer, align 8,
placebefore @foo

  define i32 @foo() nounwind uwtable readnone {
     ret i32 undef
  }

The questions is whether the LLVM developers are willing to accept
such modifications and, if yes, which approach to implementing such
modifications they would recommend.

Sergiu

[0] http://hackage.haskell.org/trac/ghc/ticket/4213