similar to: Opteron in 32-bit mode

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

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,

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

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

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

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

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

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

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

Hi, How far are we from having '-r' in the LLD COFF linker? I'd try to implement this if not too much effort is required. Any suggestions and/or pointers? Cheers, Kyra

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

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

Hi all, I do a little work on the Glasgow Haskell Compiler (GHC) which uses LLVM for the backend when compiling for Arm and some other targets. The reason I am posting to this list is that a GHC compiled program (using the LLVM backend) is getting an illegal instruction exception on the this instruction: ldr r0, [r0] According to the Arm archtecture manual:

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

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