similar to: [LLVMdev] GHC's LLVM Backend

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,

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

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, 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

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

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:

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

Hi all, When I use Clang, I can add -mno-thumb to the command line and Clang generates pure Arm code without any use of Thumb instructions. However, I am messing about with the Glasgow Haskell Compiler (GHC) which generates LLVM IR code directly and then calls `opt` and `llc` on that IR code. The generated IR code currently has: target datalayout =

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

I'm spec-ing a development server for some Haskell hackers. In particular, they need to be able to build and run the Glasgow Haskell Compiler (ghc), the x86_64 port of which isn't quite there yet. My current thought is to get an Opteron-based system, but load it (initially, at least) with the 32-bit i386 version of CentOS. That buys me near-term ghc compatibility. In the future,

Hi Valery On 13 September 2010 19:07, Valery Khamenya <khamenya at gmail.com> wrote: > are there any attempts to use LLVM in graph-rewriting (term-rewriting) > language implementations? I've added a new LLVM backend to the ghc Haskell compiler. > How good is LLVM for this? Works very well. I'm operating from the low levels of the ghc compiler though where I don't

Hi, are there any attempts to use LLVM in graph-rewriting (term-rewriting) language implementations? How good is LLVM for this? E.g., is it natural to expect that the LLVM-based implementation of the language Concurrent Clean be any faster than its reference implementation? Best regards -- Valery A.Khamenya -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, For the Glasgow Haskell Compiler's backend, we would like to let LLVM know that certain loads are safe to execute speculatively and hence to hoist out of loops. At the moment, there doesn't seem to be a mechanism for doing so. There seem to be two ways of implementing this: either allow arbitrary instructions to be marked as safe and have Instruction::isSafeToSpeculativelyExecute

Hi, I'm writing a custom alias analyser for the Glasgow Haskell Compiler's LLVM backend to teach LLVM that our explicitly-represented stack cannot alias with any heap pointer. It works, but I've hit an issue with opt's handling of alias analysers; if you specify -ghc-aa on the opt command line then LLVM only uses that analyser until (I think) a pass runs that invalidates the

On Feb 19, 2010, at 11:33 AM, james woodyatt wrote: > 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.

TL;DR: I'm trying to evaluate if LLD can be used with GHC (Glasgow Haskell Compiler) on Windows. Haskell binary code is usually deployed in "packages". A package typically provides static library(ies) and optionally – shared library(ies) and/or prelinked ('ld -r') object file. The latter is the best way to satisfy GHC runtime linker, since it requires no separate

On Jan 23, 2012, at 4:22 AM, Roman Leshchinskiy wrote: > Hello, > > For the Glasgow Haskell Compiler's backend, we would like to let LLVM know > that certain loads are safe to execute speculatively and hence to hoist > out of loops. At the moment, there doesn't seem to be a mechanism for > doing so. There seem to be two ways of implementing this: either allow >

I'm losing my sanity, so I thought I'd try and generate an LLVM target for the Glasgow Haskell Compiler (GHC). In talking to some of the people in the GHC mailing list some issues have come up that I can't find a ready answer to. (Others came up that I could, so I don't feel quite as stupid or helpless as I could.) 1. Is there any way to hint that a global pointer variable