[LLVMdev] AArch64: GHC compilation issue.
karel.gardas at centrum.cz
Wed Jan 8 13:51:32 PST 2014
On 01/ 8/14 10:24 PM, Tim Northover wrote:
> Hi Karel,
>> I've observed the same issue with LLVM 3.4 as distributed by Ubuntu 13.10
>> and with LLVM HEAD compiled on January 6. I'm able to provide the byte-code
>> file which results in this issue, but would first like to know if this is a
>> known issue in AArch64 target support or if I shall submit it somewhere or
>> even if I did some mistake in invoking llc or providing wrong set of options
>> to it.
> I've certainly not seen similar. Usually "Cannot select" errors are
> fixed very quickly since they're so easy to narrow down and fix. I
> think this is a real bug and the .ll file would be very useful.
the bziped2 file is here for you https://app.box.com/s/0i43c5j1bq40yheocmn9
>> It compiles to amd64 code by default so I added just -march=aarch64
>> and was in impression that it should be enough to target AArch64 platform...
>> If that's wrong, please let me know.
> That's on the edge of OK. There are numerous tricky ABI issues that
> could be caused by simply swapping a -march argument to LLVM . Clang,
> for example, wouldn't be able to compile correct C or C++ code with
> just that switch. But GHC presumably has less stringent ABI
> compatibility requirements, so it might get away with it.
I hope so.
> On the other hand, I think x86 (and possibly ARM) has specific code to
> handle the GHC calling conventions, which I'm fairly sure AArch64
> doesn't. That *might* just be a matter of performance, or it might be
> crucial. I kept meaning to get GHC working but never really got around
> to it.
Ah, I've not mentioned it before, but I'm attempting to port GHC to
AArch64 and the first step is to get so called unregisterised build
working. Unregisterised build does not require this specific GHC calling
convention. Once this is working I'll come here hopefully with some
patch or with ask for idea/help with modification of AArch64 target
support to make GHC calling convention a reality. But certainly I'm not
Hmm, but since you mentioned it. Has anything changed in the LLVM so
it's more easy to write such calling convention? IIRC, the calling
convention is here just to tell LLVM to omit usage of some registers as
they are pinned to the haskell virtual registers... I hope I'm not too
misleading here...And in the past creating such calling convention where
the required regs were removed was the only way probably...
More information about the llvm-dev