similar to: [LLVMdev] LLVM JIT machine detection

I'm using the Debian LLVM package to try and do JIT on a Linux armhf device. Unfortunately it seems to be generating armel code rather than armhf code, and since the ABIs don't match nothing works. 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

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

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

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 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

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,

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

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

I'd like my compiler to emit proper line number information. The docs talk about Instruction::setDebugLoc(), but that method doesn't actually have to be in my 2.7 LLVM Debian package. What's the correct way of doing this? In addition, can anyone point me at an example of how to emit a comment attached to an instruction (or function)? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────

My language is producing a lot of very short functions, typically two or three instructions long. These should be ideal candidates for inlining, but it isn't happening. My compiler is producing one big bitcode file, and all the functions are marked as 'internal'. I'm then doing the optimisation and translation manually using llc -O3 into a .s file, and then linking this against

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

I'm working on an LLVM-based compiler for a very closure-centric language. It's becoming apparent that it's going to suffer heavily from garbage collector churn, as all the useful programming idioms the language makes possible are going to involve memory allocations, either to create objects or to allocate storage for upvalues. However, it's possible to optimise away a lot of heap

My architecture has an FPU, but uses integer registers to store floating-point values. So each register can store either an int or an IEEE float. I define a register class like this: def GR32 : RegisterClass<"MyArch", [i32, f32], 32, (sequence "R%u", 0, 32)>; So far so good. However, when I write a rule to store a register: def STORE32r : S32< (outs), (ins

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

There are passes which mark function parameters as "nocapture", which means that the function does not store the passed-in pointer for use after that function returns. If pointers to a newly created object are only ever passed through "nocapture" parameters, never stored in a global, and not returned from the function, then that object is dead when the function that created

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 Sep 22, 2010, at 9:54 AM, David Given wrote: > My language is producing a lot of very short functions, typically two or > three instructions long. These should be ideal candidates for inlining, > but it isn't happening. > > My compiler is producing one big bitcode file, and all the functions are > marked as 'internal'. I'm then doing the optimisation and

What's the set of valid characters that can occur in an LLVM symbol name? The reason I ask is that my compiler is generating symbols based on method names. Some methods are operators, and I haven't got around to mangling the names yet. As a result it's producing symbols that look like _f_+ and _f_:=. LLVM seems to be coping fine with these so far and the IR output is quoting them,

Given a structure like this (using C syntax rather than LLVM because I'm still not fluent with LLVM assembly): struct Object { int i1; int i2; int i3; }; Then, if I have an int* pointer which I know is pointing to the i3 element, what's the best way of recovering a pointer to the structure as a whole? My fallback option is to cast the pointer to an int64, use getelementptr to