similar to: [LLVMdev] great (detailed) article about GHC + LLVM

On 22 February 2010 19:43, Chris Lattner <clattner at apple.com> wrote: > I found this interesting: > http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/ David Terei sent it a few days ago too, as part of another thread. (which prevented me of sharing too) ;) It's really interesting how the optimizations scrambled the code to a point of

Valery Khamenya wrote: > are there any attempts to use LLVM in graph-rewriting (term-rewriting) > language implementations? Pure is a dynamically typed FPL based on term rewriting: http://pure-lang.googlecode.com/ It uses the LLVM JIT to compile and execute code on the fly in an interpreter-like environment, and can also batch-compile code to native executables. This includes the

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:

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 21, 2010, at 4:53 PM, Garrison Venn wrote: > 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. It's here: http://llvm.org/pubs/2009-10-TereiThesis.html -Chris > > Garrison > > On Feb 21,

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

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

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

Hi, Does anyone know whether subsections are specific to the gnu assembler or whether they are supported by other assemblers, such as masm? Or put another way, will this limit the assembly output to the gnu toolchain? Cheers, Sam -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Terei Sent: 15 June 2010 14:18 To: Andrew

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

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

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

Hi all, As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Breakdown: 1) Need actual calling convention Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td 2) Handling new calling

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