[LLVMdev] Adding support to LLVM for data & code layout (needed by GHC)

Török Edwin edwintorok at gmail.com
Tue Jun 8 12:09:37 PDT 2010


On 06/08/2010 09:35 PM, John McCall wrote:
> On Jun 8, 2010, at 3:42 AM, David Terei wrote:
>> The GHC developers would like to add support to llvm to enable the
>> order that code and data are laid out in, in the resulting assembly
>> code produced by llvm to be defined by the user. The reason we would
>> like to have this feature is explained in the blog post on GHC's use
>> of llvm here: http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html,
>> specifically under the title, 'Problems with backend'.
>>
>> Basically we want to be able to produce code using llvm that looks like this:
>>
>> .text
>>    .align 4,0x90
>>    .long  _ZCMain_main_srt-(_ZCMain_main_info)+0
>>    .long  0
>>    .long  196630
>> .globl _ZCMain_main_info
>> _ZCMain_main_info:
>> .Lcg6:
>>    leal -12(%ebp),%eax
>>    cmpl 84(%ebx),%eax
>>    [...]
>>
>> So in the above code we can access the code for the function
>> '_ZCMain_main_info' and the metadata for it need by the runtime with
>> just the one label. At the moment llvm just outputs all global
>> variables at the end.
>>
>> It seems to me that there are three slightly different ways to support
>> this in llvm:
>>
>> 1) Have llvm preserve order of data and code from input file when in
>> the same section
> 
> I dislike this approach;  implicit requirements are bad.  Many clients don't care
> about the order in which variables are emitted, and indeed GHC doesn't care
> either outside of a very narrow range of constraints.
> 
> It seems to me that a module property (or special global value) holding a list of
> ordering lists would be reasonably appropriate.  Constraints:  values can only
> appear in a single list, values in a list must be definitions, and (for now) values
> in a list should not have merging linkage.

FWIW this would also help in implementing -fno-toplevel-reorder, which
is needed if llvm/clang wants to build (e)glibc. A list holding the
order of module level assembly and functions should suffice.

Best regards,
--Edwin



More information about the llvm-dev mailing list