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

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:

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

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

On Tue, Jun 8, 2010 at 4:15 PM, Eugene Toder <eltoder at gmail.com> wrote: > 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

Yes, the global structure is constant. This is indeed a side-table. Overriding section of global to be in text is simple -- LLVM already supports section attribute on globals and functions. However we also need a specific ordering in text. With some extra work this ordering can be achieved with gnu linker (I posted example implementation earlier) without any changes to LLVM, so the main points for

Hi All, The Glasgow Haskell compiler has recently become an external user of LLVM. You can read about it here: http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html If you have any comments, questions or perhaps even advice on solving some of the issues that need to be fixed in the backend going forward then please reply to this email. Cheers, David

All, I would like to submit the attached patch, which allows the GHC (Glasgow Haskell Compiler) calling convention to work on ARM targets. Could some nice person please review this code, so I can move towards getting it committed? I have thoroughly tested this patch again GHC on a Debian-ARM (armel) system. Unfortunately my understanding of LLVM is limited, so it's likely I'm not

Hi Steve, I'm not an LLVM developer but am the author/maintainer of the LLVM backend in GHC. The patch looks mostly good to me (although I am not that familiar with ARM so could easily have missed something). My main concern is why are you avoiding using the R0 - R3 registers? Also, could you please update me on the status of this work. I assume you are getting GHC running in registerised

On Feb 15, 2012, at 12:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 14, 2012, at 10:30 AM, David Terei wrote: > >> Hmm writing a blog post about TNTC is beyond the time I have right now. > > Sure, understandable. I'm surprised someone else hasn't already :) > >> Here is some high level documentation of the layout of Heap objects

On Feb 14, 2012, at 10:30 AM, David Terei wrote: > Hmm writing a blog post about TNTC is beyond the time I have right now. Sure, understandable. I'm surprised someone else hasn't already :) > Here is some high level documentation of the layout of Heap objects in GHC: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables > > With

Hmm writing a blog post about TNTC is beyond the time I have right now. Here is some high level documentation of the layout of Heap objects in GHC: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables With TNTC enabled we generate code for closures of this form: .text .align 8 .long Main_main1_srt-(Main_main1_info)+0 .long 0 .quad 4294967299 .quad 0

Hi David, > Any word on this making 3.0? 3.0 already branched, and since this is not a regression, this will most probably go into 3.1. Maybe Bill (CC'ed) being the release manager has other opinion on this. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

> This is starting to look very similar to how ARM constant islands work, without the extra ugliness from how small the ARM immediate displacements are. > > -Jim Would there be any reason that this couldn't be seen as an opportunity to move the constant islands pass out of the ARM backend and make the target-independent constant pools (which ARM bypasses completely) more generic?

everyone-- File this under Advocacy. See this thread <http://www.haskell.org/pipermail/glasgow-haskell-users/2010-February/018425.html> for more information, but the short summary is that they're deprecating their old "compile to GCC" backend in favor of David Terei's new LLVM backend. They're still planning for their C-- backend to be the primary backend for native

I found this interesting: http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/

In some language implementations, such as the Glasgow Haskell Compiler (GHC) and the reference implementation of Go, a thread’s stack is allocated as a data structure on the garbage-collected heap.  The garbage collector is free to move this data structure whenever it is invoked. Currently, GHC’s LLVM backend does not use the C stack.  However, there have been discussions about whether using the

Hi David, Your paper is linked on an LLVM site, but I can't give you the url as we are currently down for maintenance. If I remember correctly it was under "recent papers" off of the home site. Garrison On Feb 21, 2010, at 18:55, David Terei wrote: > Just to correct, the GCC back-end isn't being depreciated in favour of > the LLVM back-end (as much as I would to claim

On Feb 19, 2010, at 13:09, Chris Lattner wrote: > On Feb 19, 2010, at 11:33 AM, james woodyatt wrote: >> >> Let us all now give a warm welcome to our new Haskell comrades! > > Very nice, care to add a GHC entry to the LLVM Users page? I'll prepare a patch that could be applied when the merge is formally released by the GHC developers. — j h woodyatt <jhw at

Hi all, Just wanted to report that I've found a second way to achieve data/code layout (the first being the linker script that Eugene mentioned). The key is that gnu as supports a feature called subsections. http://sourceware.org/binutils/docs-2.20/as/Sub_002dSections.html#Sub_002dSections The way this works is that you can put stuff into a section like '.text 2', where 2 is a

OK, new patch attached. Hopefully in time for 2.7. Chris Lattner wrote: > 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. No its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will