Yes, with some modifications, both GHC HEAD and 9.4.2 Release could pass build and testsuite. However, GHC haven't implemented the support of LLVM 14 and higher versions yet, this may lead to a tardive merge in GHC side.
I don't quite understand what you mean by` CodeModel=Small` not implemented? The default CodeModel we currently define is Small, which is the same as gcc's mcmodel=normal. Medium only uses pcalau12i+jirl to increase the jumping capability relative to pc when the function is called, and the others remain unchanged, which is also the same as gcc's mcmodel=medium, currently we only provide these two codemodels(D137394 for Medium), gcc also has a mcmodel=extreme(support 64bit addressing capability). For this(extreme), I haven't figured out which CodeModel corresponds to llvm, maybe large will be better. It's going to take a while to support it, because currently no one uses it except jit. The loongson gcc team may(just maybe) also consider the implementation of mcmodel=large (support 52bit addressing capability). so? large = large? or large=extreme? - -|||
RISC-V only distinguishes when relocation-model=static is specified, but it is not required on LoongArch. On LoongArch, regardless of relocation-model=everything, it is sufficient to use pc-relative instructions.
Without the isPositionIndepent() and code-model check, original getAddr() will map the PseudoLA_GOT pattern in GHC calling convention (in ghc-cc.ll), which is obviously incorrect (should be LA_PCREL). In case that all relocation-models are sufficient to use pc-relative instructions, both CodeModel=Small and CodeModel=Medium could keep being LA_PCREL.
Personally I think using GOT or PCREL should have nothing to do with isPositionIndependent . If this test case uses -relocation-model=pic on RISC-V, it should also generate got related instructions.
In addition, I really don't understand the calling convention of ghc, is it not allowed to use got with ghc?
Basically, what GHC calling convention do is mapping the virtual registers of STG Machine (part of the Haskell Runtime System) into real registers, so here in ghc-cc.ll must be pcrel, in short, it isn't a function call, but a simple value load process, using got here will lead to load a symbol twice, which isn't a function symbol, so it will not present in GOT table. More information about this calling convention could find on GHC llvm porting
Also, using -pic or not is determined by GHC itself, and judge by its knowing behavior, isPositionIndependent is needed to avoid generating got patterns while compiling it using llvm backend.
Thanks for the contribution, I've checked against your GHC-side changes and the register convention looks good. Apart from some minor nits this should be good to go.
Is the comment still necessary? The small codemodel case is being implemented right below...
In LoongArch testcases --mattr (double-dash) is used throughout.
Please convert to opaque pointers.
LGTM, thanks very much for the contribution!
As discussed elsewhere, there's the possibility of making use of $s9 because we don't need a frame pointer, but as the GHC changes are already merged, this can come later with another pair of coordinated changes.
Any opinions on this from other reviewers?
- Could you please rebase the change? I failed to apply it to my codebase.
- It's better to add -U999999 when generating the change so that we can have more context. See: https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
I think there is no need to judge here. The following modifications(switch codemodel) should also be unnecessary. This modification will change the semantics of dso_preemptable. https://llvm.org/docs/LangRef.html#runtime-preemption-specifiers
dso_local can be used.
This is cleaner than previous revisions (which contained code model related changes) which is good. I've slightly adjusted the patch summary to remove the trivial bits and now inaccurate descriptions.
Thanks very much for the contribution!