similar to: [LLVMdev] Enabling inlining

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

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

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

On 07/09/10 14:22, Erik de Castro Lopo wrote: [...] > When generating 32 bit code the struct looks like: > > <{ i32, pointer }> > > and for 64 bit code: > > <{ union { i32, i64 }, pointer }> Surely LLVM will cause the first structure to be correctly aligned on 64-bit platforms by automatically inserting padding? Is explicit alignment by the user

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

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

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

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

On 2 September 2010 11:35, David Given <dg at cowlark.com> wrote: >> The docs >> talk about Instruction::setDebugLoc(), but that method doesn't >> actually appear to be in my 2.7 LLVM Debian package. I suggest you getting the SVN code, since quite a lot has changed since last freeze. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate

On 17/09/10 09:55, Pedro Ferreira wrote: > As I understand it, LLVM simply gives you support for garbage collectors > that you have to implement yourself and link into the final binary, > similar to what C's malloc does (it's a library call). The issue with > GC's is that they need to be provided info about the stack, thats where > LLVM's support comes in. Are there

Hi David, On 23 August 2010 15:02, David Given <dg at cowlark.com> wrote: > 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

On Sep 2, 2010, at 4:05 AM, Renato Golin wrote: > On 2 September 2010 11:35, David Given <dg at cowlark.com> wrote: >>> The docs >>> talk about Instruction::setDebugLoc(), but that method doesn't >>> actually appear to be in my 2.7 LLVM Debian package. > > I suggest you getting the SVN code, since quite a lot has changed > since last freeze.

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 08 Sep 2010, at 13:03, David Given wrote: > On 07/09/10 14:22, Erik de Castro Lopo wrote: > [...] >> When generating 32 bit code the struct looks like: >> >> <{ i32, pointer }> >> >> and for 64 bit code: >> >> <{ union { i32, i64 }, pointer }> > > Surely LLVM will cause the first structure to be correctly aligned on >

As I understand it, LLVM simply gives you support for garbage collectors that you have to implement yourself and link into the final binary, similar to what C's malloc does (it's a library call). The issue with GC's is that they need to be provided info about the stack, thats where LLVM's support comes in. As far as I know, the garbage collector is linked into the final binary

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

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

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

David Given <dg at cowlark.com> writes: > The obvious place to start on this is the C backend, except in these 2.8 > days the C backend is so hedged about with caveats I'm rather wary of > basing anything on it. I also recall seeing comments here that it's due > for a rewrite from scratch, and that various people were looking into > it. Can anyone go into more detail