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>> 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
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>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 > > > 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 http://llvm.cs.uiuc.edu > 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/7c0acea9/attachment.html>
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> > >
> the bziped2 file is here for you https://app.box.com/s/0i43c5j1bq40yheocmn9Thanks Karel. This particular issue should be fixed in trunk now (r199265). Cheers. Tim.
Tim, thanks a lot for solving this! Indeed, I've rerun my GHC unregisterised build via LLVM way and it succeed this time. Thanks! Karel On 01/14/14 11:59 PM, Tim Northover wrote:>> the bziped2 file is here for you https://app.box.com/s/0i43c5j1bq40yheocmn9 > > Thanks Karel. This particular issue should be fixed in trunk now (r199265). > > Cheers. > > Tim. >
Apparently Analagous Threads
- [LLVMdev] Please review my patch to make GHC calling convention work on ARM
- [LLVMdev] Please review my patch to make GHC calling convention work on ARM
- [LLVMdev] Request for merge: GHC/ARM calling convention.
- [LLVMdev] Request for merge: GHC/ARM calling convention.
- [LLVMdev] Request for merge: GHC/ARM calling convention.