similar to: [LLVMdev] On large vectors

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

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

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

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

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

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

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)? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────

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

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 26/01/13 19:20, Torsten Rüger wrote: [...] > Just at the end it mentions closures and I was wondering how those are done in llvm. > The link was to wikipedia, and i do know what closures/blocks/continuations are, (i think) but maybe someone could point me to where to read about how to do them in llvm. I've implemented closures in the past --- it's fiddly and a surprising amount

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

Hello, For a while I've been working on an LLVM backend for Broadcom's VideoCore 4, the GPU made famous by the Raspberry Pi. This isn't the QPU, for which Broadcom released docs a little while ago; it's the main processor, which is a VC4 core. It's a rather elegant thing with two cores, 32 registers, a built-in DSP and an extremely nice instruction set; reverse engineered