LLVM mtriple for aarch64-win32-msvc ?

Is there a way to use LLC to cross-compile some code to run on Windows IOT on Raspberry Pi ?

I was able to convince LLVM to spit out some bitcode for this, but when I try llc it dumps:

llc.exe test.bc -o test.obj -filetype=obj -O3 -mtriple=aarch64-win32-msvc -mcpu=cortex-a53
Wrote crash dump file “C:\Users\clovett\AppData\Local\Temp\llc.exe-4990d8.dmp”
0x0000000000000000 (0x0000000000000000 0x000001AE351C38E9 0x0000000000000007 0x000001AE351C38F1)
0x00007FF79681B7F5 (0x000001AE3526BFE0 0x000001AE35216D40 0x000001AE3526BFE0 0x000000047738EE80)
0x00007FF79681AEF6 (0x0000000000000000 0x000000047738F0D0 0x000001AE32C27BC0 0x000001AE3526BFE0)
0x00007FF79602EEDC (0x000001AE32C27BC0 0x0000000000000000 0x0000000000000000 0x0000000000000008)
0x00007FF79603056D (0x0000000000000000 0x000001AE32C49800 0x00007FFD3B3D69D8 0x0000000000000000)
0x00007FF796D82DE9 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FFD3D712774 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 bytes(s)
0x00007FFD3E420D51 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart()

Is there a way to use LLC to cross-compile some code to run on Windows IOT on Raspberry Pi ?

I was able to convince LLVM to spit out some bitcode for this, but when I try llc it dumps:

How was the bitcode generated?

Also, regardless of that, llc shouldn't crash... so this is a bug. A bug report with reproducible steps would be useful.

Jon

Windows 10 IoT on Raspberry Pi (or anywhere else) is just 32 bit arm for now, so you want to try the armv7-win32-msvc target triplet instead.

(There is some preliminary support for aarch64-win32 targets also; it seems to work for C code for things I've tested so far, but e.g. C++ support is incomplete. And there's no public aarch64 windows version out at all yet, it's supposedly coming late this year though. So far I've been testing it with wine.)

// Martin

Thanks Martin, I’m generating the code using LLVM (writing llvm::Triple myself and llvm::TargetRegistry::lookupTarget is working), and that’s how my bitcode is generated then using LLC to cross-compile that.

So using armv7-win32-msvc is getting me a bit closer, but what CPU, raspberry pi 3 is running a Cortext-A53, but when I specify that in -mcpu argument I get this error:

I think I remember from discussions with Saleem that Windows only
supports code running in Thumb mode, so using "thumbv7" at the start
of the triple is probably a lot more likely to work.

That said, I have no idea why it's complaining about the Cortex-A53
CPU, that definitely supports ARM mode. It put it down to gremlins
producing random, non-helpful messages.

Cheers.

Tim.

Indeed, that's correct. Within the clang frontend, we remap all armv7-win32 to thumbv7-win32 internally, and for various reasons I've kept using the armv7 named triplet in my own command lines.

// Martin

Yeah, Windows 10 is a pure thumb2 environment. Although it is possible to execute ARM mode code, any context switch into kernel space can cause problems (they do not guarantee that you will be in ARM mode when you come back). For that reason, we simply force everything is generated in thumb mode only. When using clang, we allow the user to specify armv7-unknown-windows-msvc as the triple and map that to thumbv7-unknown-windows-msvc.