<div dir="ltr"><div><div>Karel, step 1 of the ghc llvm porting guide <a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting</a><br>
</div>specifically says "make sure unregisterized builds with the c backend work"<br><br></div>cheers :) <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 4:39 PM, Karel Gardas <span dir="ltr"><<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.cz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Carter,<br>
<br>
small misunderstanding. I'm not dealing with unregisterised via C build, but with unregisterised with LLVM, which is a little bit different beast.<br>
<br>
Cheers,<br>
Karel<div class="im"><br>
<br>
On 01/ 9/14 10:23 PM, Carter Schonwald wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hey Karel,<br>
the GHC unregisterized via C code gen requires using GCC. Unless Clang<br>
starts support some of the more eclectic GCC C extensions, you wont' be<br>
able to use Clang/LLVM for doing an unregisterized build.<br>
<br>
GCC 4.8 and newer seems to have aarch64 support.<br>
<br>
cheers!<br>
-Carter<br>
<br>
<br>
On Wed, Jan 8, 2014 at 4:51 PM, Karel Gardas <<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.cz</a><br></div><div class="im">
<mailto:<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.<u></u>cz</a>>> wrote:<br>
<br>
<br>
Hi Tim,<br>
<br>
<br>
On 01/ 8/14 10:24 PM, Tim Northover wrote:<br>
<br>
Hi Karel,<br>
<br>
I've observed the same issue with LLVM 3.4 as distributed by<br>
Ubuntu 13.10<br>
and with LLVM HEAD compiled on January 6. I'm able to<br>
provide the byte-code<br>
file which results in this issue, but would first like to<br>
know if this is a<br>
known issue in AArch64 target support or if I shall submit<br>
it somewhere or<br>
even if I did some mistake in invoking llc or providing<br>
wrong set of options<br>
to it.<br>
<br>
<br>
I've certainly not seen similar. Usually "Cannot select" errors are<br>
fixed very quickly since they're so easy to narrow down and fix. I<br>
think this is a real bug and the .ll file would be very useful.<br>
<br>
<br>
the bziped2 file is here for you<br></div>
<a href="https://app.box.com/s/__0i43c5j1bq40yheocmn9" target="_blank">https://app.box.com/s/__<u></u>0i43c5j1bq40yheocmn9</a><div><div class="h5"><br>
<<a href="https://app.box.com/s/0i43c5j1bq40yheocmn9" target="_blank">https://app.box.com/s/<u></u>0i43c5j1bq40yheocmn9</a>><br>
<br>
<br>
It compiles to amd64 code by default so I added just<br>
-march=aarch64<br>
and was in impression that it should be enough to target<br>
AArch64 platform...<br>
If that's wrong, please let me know.<br>
<br>
<br>
That's on the edge of OK. There are numerous tricky ABI issues that<br>
could be caused by simply swapping a -march argument to LLVM .<br>
Clang,<br>
for example, wouldn't be able to compile correct C or C++ code with<br>
just that switch. But GHC presumably has less stringent ABI<br>
compatibility requirements, so it might get away with it.<br>
<br>
<br>
I hope so.<br>
<br>
<br>
On the other hand, I think x86 (and possibly ARM) has specific<br>
code to<br>
handle the GHC calling conventions, which I'm fairly sure AArch64<br>
doesn't. That *might* just be a matter of performance, or it<br>
might be<br>
crucial. I kept meaning to get GHC working but never really got<br>
around<br>
to it.<br>
<br>
<br>
Ah, I've not mentioned it before, but I'm attempting to port GHC to<br>
AArch64 and the first step is to get so called unregisterised build<br>
working. Unregisterised build does not require this specific GHC calling<br>
convention. Once this is working I'll come here hopefully with some<br>
patch or with ask for idea/help with modification of AArch64 target<br>
support to make GHC calling convention a reality. But certainly I'm not<br>
there yet...<br>
<br>
Hmm, but since you mentioned it. Has anything changed in the LLVM so<br>
it's more easy to write such calling convention? IIRC, the calling<br>
convention is here just to tell LLVM to omit usage of some registers as<br>
they are pinned to the haskell virtual registers... I hope I'm not too<br>
misleading here...And in the past creating such calling convention where<br>
the required regs were removed was the only way probably...<br>
<br>
Thanks!<br>
Karel<br>
<br>
<br></div></div>
______________________________<u></u>___________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/__<u></u>mailman/listinfo/llvmdev</a><br>
<<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a>><br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>