similar to: [LLVMdev] Dataflow analysis based optimisations

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

On 28/08/10 02:20, Kenneth Uildriks wrote: > 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

On 02/09/10 18:28, Jim Grosbach wrote: > On Sep 2, 2010, at 4:05 AM, Renato Golin wrote: [...] >> I suggest you getting the SVN code, since quite a lot has changed >> since last freeze. > > Vigourously seconded. It's very true in general, but with regards to debug information in particular, "quite a lot has changed since 2.7" is an understatement. It's an

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

On 2 September 2010 19:16, David Given <dg at cowlark.com> wrote: > I really don't want to build from SVN --- developing against a moving > target is never fun, and apart from anything else, it makes it much > harder for anyone else to use my code. Actually, unless you're planning to release your code in less than 2 months, developing in the SVN makes much more sense than

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

On Sat, Aug 28, 2010 at 10:53 AM, David Given <dg at cowlark.com> wrote: > On 28/08/10 02:20, Kenneth Uildriks wrote: >> 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

On 29/08/10 16:28, Kenneth Uildriks wrote: [...] > Now the case where function A calls function B, and function B needs > to return a pointer to a freshly-allocated object, is fairly common. > One way to attack this is to have each function create its own > "region" or "memory pool" and destroy it when it returns. [...] > This > scheme will allow any call

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

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

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

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

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

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

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,

For a hypothetical Evil Project(tm), I would like to do a LLVM backend for a virtual machine that does not use 8-bit bytes. Does LLVM support this sort of thing? The details are: each addressing unit in the virtual machine can store a single value of any type, except for data pointers, which are stored as pairs (handle and offset). As such, sizeof(char) == sizeof(int) == sizeof(long long) ==

Hi David, > [(set GR32:$rD, globaladdr:$addr)] > It seems to have somehow managed to create a cycle in the DAG, which is > of course wrong. But how? When I write a similar pattern into the ARM .td files and look at (from the build directory) lib/Target/ARM/ARMGenDAGISel.inc, I see: /*56478*/ /*SwitchOpcode*/ 13, TARGET_VAL(ISD::GlobalAddress),// ->56494 /*56481*/

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