search for: ghc

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

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

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

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

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

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 the patch itself is short and easy to read and it should not affect other parts of...

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

...ect. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9, D10, D11]>>, > + CCIfType<[f32], CCAssignToReg<[S16, S17, S18, S19, S20, S21, S22, S23]>>, > > Does this mean that for floating point support in GHC, you need VFP registers? 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 floa...

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 carry around our own version of LLVM...

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 creating trampolines for "far" code to fulfill...

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

Hi all, I'm hitting a segfault in llc when trying to build GHC: http://sprunge.us/ZVGB. What is the best way to debug this? I'm able to bump to 3.8.1 if needed, but GHC tends to break when updating major versions due to IR incompatibilities. Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type...

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 > allocated in RAM...

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 Function *F = MF->getFunction(); >>>> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); >>>> > + } >>>> >>>> > This...

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

Hi Duncan, On 10/14/11 03:56 PM, Duncan Sands wrote: > Hi Karel, > >> > const unsigned* >> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >> const { >> > + bool ghcCall = false; >> > + >> > + if (MF) { >> > + const Function *F = MF->getFunction(); >> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); >> > + } >> >> > This bit looks dubious. Why do you need to do it? >> &g...

...that's wrong, please let me know. > > That's on the edge of OK. There are numerous tricky ABI issues that > could be caused by simply swapping a -march argument to LLVM . Clang, > for example, wouldn't be able to compile correct C or C++ code with > just that switch. But GHC presumably has less stringent ABI > compatibility requirements, so it might get away with it. I hope so. > On the other hand, I think x86 (and possibly ARM) has specific code to > handle the GHC calling conventions, which I'm fairly sure AArch64 > doesn't. That *might* just be...

Hi Karel, >>> > const unsigned* >>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>> const { >>> > + bool ghcCall = false; >>> > + >>> > + if (MF) { >>> > + const Function *F = MF->getFunction(); >>> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); >>> > + } >>> >>> > This bit looks dubious. Why do yo...

...right... The rest looks correct. + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, + CCIfType<[f64], CCAssignToReg<[D8, D9, D10, D11]>>, + CCIfType<[f32], CCAssignToReg<[S16, S17, S18, S19, S20, S21, S22, S23]>>, Does this mean that for floating point support in GHC, you need VFP registers? I don't know much how tablegen would work in this case, but I'd expect it to break during codegen (with a horrid error message) if you try to compile that to an ARMv4-ish core. Maybe you need a warning/error during codegen (if GHC && !hasVFP -> error)...

Hi Erik, > GHC does not generate or use thumb instructions From you assembly dump, looks like the instructions are 2 bytes long, meaning it's Thumb code not ARM. - Denis. > Owen Shepherd wrote: > >> Pay closer attention to the instruction descriptions on the page you linked >> above: >...