[LLVMbugs] [Bug 14080] New: Support GHC (Haskell) Tables-next-to-code

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=14080

             Bug #: 14080
           Summary: Support GHC (Haskell) Tables-next-to-code
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is a design bug for accumulation the ideas of the TNTC feature that GHC
Haskell needs.

http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html describes
the Haskell LLVM backend. At the end it details the TNTC problem.

There is a hack in place for merging (object sections) that achieves the same
effect on sufficiently capable platforms, but clean support would be
preferable.

So far following ideas have been discussed:
   (please feel free to comment on this if you have more ideas)

1) LLVM construct to connect Data with Code ('before <code>' annotation on
globals or 'after <data>' annotation on code)

2) some intrinsic that directs the code generator to 'inline' global data into
the code (and a corresponding intrinsic to extract the data from a function
pointer):
   - llvm.inlinedata.before <global>
   - llvm.extract.inlinedata <function> --> <data>

3) parametrizable calling convention; a new calling convention that specifies
what data should be made available in a function-relative position.
This would allow to use special 'nop' (or fixed-offset branch) instructions to
encode the data in opcodes. These usually do not cost on modern processors.

Discussion:

1) is frowned upon, as it needs .ll-parser changes for a very specific feature

2) sounds very generic and probably only needs (target-unspecific) codegen
changes (besides declaring the intrinsics).

3) again parser changes, but best describes the TNTC semantics in Haskell. How
to embed pointers is an open question. Target specific feature. Usually only a
few bits of data is needed anyway, and GHC's TNTC already wastes many bits.

2a/3a) certain ABIs require code descriptors already (e.g. PowerOpen PPC64 ABI)
for cross shlib calls. The tables could be added to these conveniently.

Additional material:

 - http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047514.html
 - GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/4213
 - http://blog.davidterei.com/2011/09/ghc-project-for-all.html

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.