[LLVMdev] AArch64: GHC compilation issue.

[Carter Schonwald]

Karel, step 1 of the ghc llvm porting guide
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting
specifically says "make sure unregisterized builds with the c backend work"

cheers :)


On Thu, Jan 9, 2014 at 4:39 PM, Karel Gardas <karel.gardas at centrum.cz>wrote:

>
> Carter,
>
> small misunderstanding. I'm not dealing with unregisterised via C build,
> but with unregisterised with LLVM, which is a little bit different beast.
>
> Cheers,
> Karel
>
>
> On 01/ 9/14 10:23 PM, Carter Schonwald wrote:
>
>> Hey Karel,
>> the GHC unregisterized via C code gen requires using GCC. Unless Clang
>> starts support some of the more eclectic GCC C extensions, you wont' be
>> able to use Clang/LLVM for doing an unregisterized build.
>>
>> GCC 4.8 and newer seems to have aarch64 support.
>>
>> cheers!
>> -Carter
>>
>>
>> On Wed, Jan 8, 2014 at 4:51 PM, Karel Gardas <karel.gardas at centrum.cz
>> <mailto:karel.gardas at centrum.cz>> wrote:
>>
>>
>>     Hi Tim,
>>
>>
>>     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
>>
>>     <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
>>     there yet...
>>
>>     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...
>>
>>     Thanks!
>>     Karel
>>
>>
>>     _________________________________________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>>     <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140109/00ac9a24/attachment.html>