search for: fastcc_arm_apcs

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

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,

...ocated in RAM instead of real hardware regs. That's fine. As long as you don't try to interoperate with EABI libraries... ;) > 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. APCS is deprecated almost a decade, not sure there is anyone on the planet using that... except maybe Nokia... ;) You mentioned it's #ifdefed, so I guess you won't have that probl...

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