Karel Gardas
2012-Jun-24 14:18 UTC
[LLVMdev] Request for merge: GHC/ARM calling convention.
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 LLVM complained to me about unsupported calling convention which was surprising for me and I've gone for a little bit investigation and found all the GHC/ARM calling convention code missing from it. So I've grabbed LLVM HEAD and applied the GHC/ARM calling convention patch to it with some tweaks to resolve rejects. I've also changed a patch a little bit to use LLVM's facility to generate callee-saved regs list automatically from ARMCallingConv.td. However either I don't know well syntax for callee save regs specification or the tool does not support empty list, I've needed to use simple work around to come to the same result as was in the previous patch version. (For those interested, the error with empty list was "expected identifier in dag init") +// GHC set of callee saved regs is empty as all those regs are +// used for passing STG regs around +// sub/add LR is a workaround for not being able to compile empty list: +// def CSR_GHC : CalleeSavedRegs<()>; +def CSR_GHC : CalleeSavedRegs<(sub (add LR), LR)>; otherwise, the patch is the same like it was merged into 3.0 release as submitted here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html Please see attached patch and tell me if it's all right for inclusion into LLVM HEAD or not and if not, what else shall I provide in order to make LLVM team happy about it. BTW: of course, LLVM HEAD with this patch applied is already tested here with GHC 7.4.2. (i.e. the compiler bootstrap well with it) and LLVM's own testsuite does not reveal any new regression caused by this patch. Thanks a lot! Karel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ghc-arm-llvm.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120624/891b3ca2/attachment.ksh>
Renato Golin
2012-Jun-24 22:13 UTC
[LLVMdev] Request for merge: GHC/ARM calling convention.
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, 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) to make it clear to the user. I think it's ok to assume ARMv5+ for Haskell code... ;) cheers, --renato
Karel Gardas
2012-Jun-29 16:46 UTC
[LLVMdev] Request for merge: GHC/ARM calling convention.
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, 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 floating points regs are then allocated in RAM instead of real hardware regs.> 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.I'm not sure I understand you right here, but if you look into ARMCallingConv.td file, you will see that exactly the same statements are used in FastCC_ARM_APCS so I think if it's going to be broken, then the GHC calling convention is not the only culprit here. Or are you talking about actual compilation for the target platform? Anyway, I think majority of GHC/ARM related work will be done on ARMv7 if it makes you less nervous about the patch. Thanks, Karel
Marshall Clow
2012-Aug-01 03:14 UTC
[LLVMdev] Request for merge: GHC/ARM calling convention.
On Jun 24, 2012, at 7:18 AM, Karel Gardas <karel.gardas at centrum.cz> wrote:> > 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 LLVM complained to me about unsupported calling convention which was surprising for me and I've gone for a little bit investigation and found all the GHC/ARM calling convention code missing from it. > > So I've grabbed LLVM HEAD and applied the GHC/ARM calling convention patch to it with some tweaks to resolve rejects. I've also changed a patch a little bit to use LLVM's facility to generate callee-saved regs list automatically from ARMCallingConv.td. However either I don't know well syntax for callee save regs specification or the tool does not support empty list, I've needed to use simple work around to come to the same result as was in the previous patch version. (For those interested, the error with empty list was "expected identifier in dag init") > > +// GHC set of callee saved regs is empty as all those regs are > +// used for passing STG regs around > +// sub/add LR is a workaround for not being able to compile empty list: > +// def CSR_GHC : CalleeSavedRegs<()>; > +def CSR_GHC : CalleeSavedRegs<(sub (add LR), LR)>; > > otherwise, the patch is the same like it was merged into 3.0 release as submitted here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html > > Please see attached patch and tell me if it's all right for inclusion into LLVM HEAD or not and if not, what else shall I provide in order to make LLVM team happy about it. > > BTW: of course, LLVM HEAD with this patch applied is already tested here with GHC 7.4.2. (i.e. the compiler bootstrap well with it) and LLVM's own testsuite does not reveal any new regression caused by this patch. > > Thanks a lot! > KarelAnyone know the status of this patch? Did it get applied? Rejected? Ok'ed but not applied? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists at gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Karel Gardas
2012-Aug-01 08:17 UTC
[LLVMdev] Request for merge: GHC/ARM calling convention.
On 08/ 1/12 05:14 AM, Marshall Clow wrote:> Anyone know the status of this patch? > Did it get applied? Rejected? Ok'ed but not applied?Hello, as far as I know, it's not presented in today's HEAD. Thanks, Karel
Maybe Matching Threads
- [LLVMdev] Request for merge: GHC/ARM calling convention.
- [LLVMdev] Request for merge: GHC/ARM calling convention.
- [LLVMdev] Request for merge: GHC/ARM calling convention.
- [LLVMdev] Request for merge: GHC/ARM calling convention.
- [LLVMdev] Request for merge: GHC/ARM calling convention.