This is a special calling convention to be used by the GHC compiler.
i32 works too, as with the fast calling convention. That way you can support RV32.
(Though maybe both should be asserting if they ever see an i64 on RV32 given that's not a legal type? Or just leave it up to the general legalisation/verification stuff)
Do you have an explanation somewhere for why you've chosen these X and F registers for the calling convention? It'd also be useful to give their RISC-V ABI names here in the comments as the numbered registers aren't so easy to keep track of mentally.
Shouldn't this be a hard error? Otherwise it'll fall back on the normal C calling convention like for Fast, no?
|1–3 ↗||(On Diff #299391)|
Please make this match the other tests in here, ie:
Is this doable with the declarative Calling Convention system in LLVM (an example of this is in llvm/lib/Target/ARM/ARMCallingConv.td)
We haven't been able to do this for RISC-V's normal calling convention yet, but this convention seems a lot simpler, so I hope it should be doable.
|1–3 ↗||(On Diff #299391)|
Hm right you'd need i32. We pipe things through sed in our fork to s/\<iXLEN\>/i64/ etc but I don't think the upstream update_llc_test_checks.py likes that (though maybe it does these days?). You'd have to duplicate the file otherwise as is done for calling-conv-ilp32.ll and calling-conv-lp64.ll.
What happens if you try and use a soft-float or single-float ABI with ghccc? Will GHC know to use integer registers instead, or will this cause errors that mean we need to validate the ABI+CC combination?
|1 ↗||(On Diff #300488)|
Please use "ghccc" rather than "ghc-cc" in the names of these files to match the calling convention name (as is done with the fastcc tests).
|1–2 ↗||(On Diff #300488)|
Please use update_llc_test_checks.py for these.
Overall, LGTM. Two things, though:
- Please fix the < %s issue before committing, otherwise the test will fail.
- Having a test for the error conditions would really round off this patch. I don't think that needs to be a blocker for merging this, but it would be nice.
This is missing the < %s at the end of the llc command options.
In the CallingConvLower.h, the CCAssignFn is a function pointer that represent the function that deal with the calling convention, and this function can be used in many other places, for example, In globalisel's ValueHandler. So I think use the TableGen rather than C++ is more convenient.
If GlobalISel can’t work with what’s already there then it needs to be fixed, because the current code is rather complex and won’t be being converted any time soon, and as a downstream consumer of the backend who extensively adds to the calling convention that would cause serious headache (and depending on how the rewriting is done may not even support our use case without additional downstream changes to TableGen, something that would be a real pain to do). IMO GlobalISel as a new framework needs to adapt to fit the existing backends unless there is a good reason why it fundamentally cannot.