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

[Eugene Toder]

Let me point out that projects using standard toolchain (e.g.
binutils) can already reorder code and data pretty much arbitrary
using sections and linker scripts.
I think it's still attractive to have reordering in LLVM to be
independent from external toolchain. This will allow reordering in JIT
and other interesting things.

I agree with John that special global with ordered list looks like the
clean approach. However, for the specific need in GHC I'm not sure
that this is enough.
What it's trying to do is placing a global variable (a struct) and a
function next to each other, so that it can use pointer arithmetic to
go from one address to another.
So, say, we take the address of the struct, add it's size and call
into resulting address. Sufficiently smart optimizer can spot that we
dereference a pointer pointing outside of the object. This probably
has undefined semantics and can be replaced with unreachable?
It's also a missed opportunity for optimizations -- if optimizer knew
where outside-of-the-struct pointer is really going it could make
direct call instead of indirect -- however, I don't know if this is a
big deal.


Eugene

On Tue, Jun 8, 2010 at 3:50 PM, Sebastian Redl
<sebastian.redl at getdesigned.at> wrote:
>
> On Tue, 8 Jun 2010 11:42:41 +0100, David Terei <davidterei at gmail.com>
> wrote:
>> Hi All,
>>
>> 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'.
>>
>
> Whichever way is chosen, the ability to reorder and intermingle functions
> and data arbitrarily is interesting to more than just GHC. In particular, I
> would like to point out the efforts by Mozilla to make Firefox startup
> faster, which essentially came down to reordering stuff in the executables
> so that everything is ordered by the sequence of accesses during program
> startup. This means that programs can be read sequentially from the front
> to the end, thus reducing I/O latency.
>
> Tools for automating this process would probably benefit from being able
> to specify the layout this way.
>
> Sebastian
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>