similar to: [LLVMdev] On calling intrinsics

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

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Given > Subject: [LLVMdev] On calling intrinsics > if I try to use llvm.ceil.f64, I get an unresolved symbol error That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2; one for floor exists, but not ceil. However, ceil is defined in trunk, so

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,

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

So I read the Kaleidoscope tutorial, big thanks to Chris Latter. Good pace, still excellent coverage. 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. Thanks Torsten

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

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 22/01/13 05:30, Redmond, Paul wrote: [...] > I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) > > Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily 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

Hi, I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function. Therefore it makes sense to

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,

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

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

Using the following example program #include <math.h> double f(double d){ return sqrt(d); } and compiling it with "clang -O3 ...", I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a sqrtsd instruction inline. It turns out that it could do exactly that, were it not for the fact that in the function

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

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

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