similar to: Replace call stack with an equivalent on the heap?

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

On Feb 2, 2014, at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: >> The result of such a system would produce weights for every block in the above CFG as '1.0', or equivalent to the entry block weight. This to me is a really useful metric -- it indicates that no block in the CFG is really more or less likely than any other. Only *biases* in a specific direction would

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

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 10/10/2017 9:00 PM, Rui Ueyama wrote: > I'm not sure if I understand correctly. If my understanding is > correct, you are saying that GHC can link either .o or .so at runtime, > which sounds a bit odd because .o is not designed for dynamic linking. > Am I missing something? Yes, GHC runtime linker *does* link .o files not only doing all necessary relocations but also

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

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

David, Thanks for that - I emailed Karel Gardas. I've got GHC successfully registerised on ARM, and I'm just starting on pushing it upstream. The reason why I'm avoiding the R0-R3 registers is mainly because my qemu-based ARM VM takes days to compile everything, and I was being conservative. The GHC code can call directly out to C, so it would need to save its own R0-R3 when it

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > 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. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to

Hello, first of all: one of the LLVM 3.0 new feature was a support for GHC specific calling convention on ARM platform. It looks like this support was merged just into 3.0 branch, specifically it appeared in 3.0 RC2. Anyway, I hope this is just a mistake or omission that such support was merged only into 3.0 and not also into HEAD. I've just found it by testing LLVM 3.1 with GHC 7.4.2 and

Hi Renato, On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9,

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >

Hi Duncan, Karel, On 14 October 2011 08:22, Duncan Sands <baldrick at free.fr> wrote: > Hi Karel, > >>>> > const unsigned* >>>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>>> const { >>>> > + bool ghcCall = false; >>>> > + >>>> > + if (MF) { >>>> > + const

Hi all, I do a little work on the GHC haskell compiler. One of the things I do is compile current GHC git HEAD against the next release of LLVM to find issues and adapt the GHC code as early as possible. A recent modification to LLVM is now rejecting GHC generated LLVM IR that was previously accepted. I discussed this on IRC with sanjoyd who explained what had changed and gave me some hints

Hello, today is the last day[1] when someone might ask for feature merge into the LLVM 3.0 release. I'd like to ask you to merge attached patch. This is implementation of GHC calling convention on ARM platform which is made by Stephen Blackheath with few additions by me. I hope that although the patch does not contain any test case, it still will be merged. The reason for this is that

Hi Tim, On 01/ 8/14 10:24 PM, Tim Northover wrote: > Hi Karel, > >> I've observed the same issue with LLVM 3.4 as distributed by Ubuntu 13.10 >> and with LLVM HEAD compiled on January 6. I'm able to provide the byte-code >> file which results in this issue, but would first like to know if this is a >> known issue in AArch64 target support or if I shall submit

Hello, I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

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 Jim and Eric! thanks a lot for your fantastically fast reply. I'm going to update and will report tomorrow when all the building is done. Thanks! Karel On 08/29/11 11:36 PM, Jim Grosbach wrote: > Hi Karel, > > Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. > > -Jim > > On Aug 29, 2011, at 2:33