similar to: [LLVMdev] JIT on armhf

On 8 February 2013 11:01, David Given <dg at cowlark.com> wrote: > I've tried overriding the triple to arm-unknown-linux-gnueabihf and > arm-linux-gnueabihf (via module->setTargetTriple), and while the triples > are accepted, the actual generated code doesn't change with either. > Hi David, If you set the triple to arm it won't help, since it'll default to

Renato Golin wrote: [...] > Try setting armv7a-unknown-linux-gnueabihf and see if it works better. No, that doesn't work either. [...] > JIT was never the forte of ARM and I haven't tried yet, but I doubt > it'll be any Debian misconfiguration. The whole architecture > configuration is a bit odd... Debian's clang packages are totally broken on armhf --- the compiler

How does the LLVM JIT determine the ABI and architecture to generate code for? I ask because I have an armhf device (running Debian, sort of), except the JIT is generating soft-float code. This isn't ABI compatible as parameters are passed in the wrong registers, and so simply doesn't work. Is this something that I, as an LLVM library user, should not need to worry about (and therefore

I have a simple expression-evaluation language using LLVM (it's at https://cowlark.com/calculon, if anyone's interested). It has pretty primitive support for 3-vectors, which I'm representing as a <3 x float>. One of my users has asked for proper n-vector support, and I agree with him so I'm adding that. However, he wants to use quite large vectors. He's mentioned 30

Moshe, Nir wrote: [...] > I have a question about the LLVM ARM backend: > > I try to build *.c files for Windows Phone (Windows 8) - so, basically > I need to generate an "arm-pe" file (I *think* it has the same file > structure like x86-pe file, but i am not sure). > unfortunately, LLVM has no support with ARM PE\COFF. We recently ran into this. Unfortunately

Hi guys, I have a question about the LLVM ARM backend: I try to build *.c files for Windows Phone (Windows 8) - so, basically I need to generate an "arm-pe" file (I *think* it has the same file structure like x86-pe file, but i am not sure). unfortunately, LLVM has no support with ARM PE\COFF. Any ideas? How difficult is to add the support in this file format? (LLC can generate ARM

On 7/23/14, 1:20 PM, Tim Northover wrote: [...] > You should probably be specifying a triple directly, and making it an > AAPCS-VFP one for good measure: "armv7-linux-gnueabihf" for example, > or "thumbv7-none-eabihf". You shouldn't even need to set FloatABI for > those two. How do I do this? (I can't find any examples, and the API is decidedly unclear...)

On 8 February 2013 14:28, David Given <dg at cowlark.com> wrote: > Debian's clang packages are totally broken on armhf --- the compiler > emits a confused warning about the platform being unrecognised, and then > generates softfloat code --- so I was wondering about LLVM itself. I'm using Ubuntu on Pandas and Chromebooks and LLVM itself behaves well, with the right set of

On 7/23/14, 3:30 PM, Tim Northover wrote: [...] > It looks like it's a case of calling Module::setTargetTriple. As with > most JIT setup questions, though, often the best way to find out is to > get something working in lli and then look at what it does > (tools/lli/lli.cpp). Well, it's *almost* working --- hardfloat code is now being generated, and it even seems to be right

Hello, Last year I tried --- and failed --- to generate float-heavy ARM code via the JIT on an armhf platform. No matter what I did, it would always generate armel code instead. This was on LLVM 3.2, which was all that was available then. Now I'm running into a requirement to do this again: while it's much less crashy than it was, I still can't seem to persuade the JIT to generate

On 08/02/13 14:42, Renato Golin wrote: [...] > Can you paste the result of a "clang -v -mcpu=CPU file.c" on your box? I > want to see what are the arguments and the assembler/linker it's > choosing to use. What CPU are we talking about? The box itself is an Allwinner A10; armv7l. /proc/cpuinfo says it's got swp half thumb fastmult vfp edsp neon vfpv3. I've been

On 8 February 2013 21:42, David Given <dg at cowlark.com> wrote: > The box itself is an Allwinner A10; armv7l. /proc/cpuinfo says it's got > swp half thumb fastmult vfp edsp neon vfpv3. > Yes, it's a Cortex-A8. I've been unable to find any values for CPU which are accepted (it just > says 'unknown target CPU'. I've tried arm, armv7, armv7a, armv7l,

Renato Golin wrote: [...] > I can see why freakishly large vectors would produce bad code. The > type <50 x float> would be widened to the next power of two, and > then split over and over again until it fits into registers. So, > any <50 x float> would take 16 XMM registers, that will be spilled. > The situation with integer types is even worse

On 6 February 2013 17:03, Nadav Rotem <nrotem at apple.com> wrote: > I can see why freakishly large vectors would produce bad code. The type > <50 x float> would be widened to the next power of two, and then split over > and over again until it fits into registers. So, any <50 x float> would > take 16 XMM registers, that will be spilled. The situation with integer

I can see why freakishly large vectors would produce bad code. The type <50 x float> would be widened to the next power of two, and then split over and over again until it fits into registers. So, any <50 x float> would take 16 XMM registers, that will be spilled. The situation with integer types is even worse because you can truncate or extend from one type to another. On Feb 6,

On 7/24/14, 7:18 AM, Tim Northover wrote: [...] > Which triple are you using? And is the correct code used when you run > the same IR through "llc -mtriple=whatever"? armv7-linux-gnueabihf, as suggested; and if I use llc -mtriple then the code compiles to: vstr s0, [r0] bx lr ...which I would consider correct. (What's more interesting is *without* specifying the triple

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

On 08/02/13 15:42, David Tweed wrote: > | For ARM, you will need to use the MCJIT ExecutionEngine as the legacy > | one is broken for ARM. (call EngineBuilder::setUseMCJIT()). > > Also remember to include the correct MCJIT headers not the JIT one's: > calling setUseMCJIT() with the old JIT headers are the only ones being > included just constructs an old JIT, it doesn't

Hello again Christian, I've posted https://reviews.llvm.org/D55709 to see if we can get the documentation on how to cross-compile compiler-rt improved. I'll be out of office until next year so I may be a bit slow to respond to any follow ups. Peter On Thu, 13 Dec 2018 at 17:10, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Christian, > > I've just

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar