llvm dev - Jun 2012 - [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>

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

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

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!
> Karel
Anyone 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

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