[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