similar to: [LLVMdev] Indexing backwards through a structure

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

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

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

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

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

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

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

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

Chris Lattner wrote: > I removed unions from mainline in r112356. Sorry for reviving this old thread, but I think the removal of unions is a real pity. I use Haskell to generate LLVM code using David Terei's LLVM code from the GHC compiler (the compiler I'm working on is also written in Haskell). Once I've generated LLVM IR code I use llc to generate object code. I'm

On 02/09/10 11:27, David Given wrote: > 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? Grr stupid typo. > The docs > talk about Instruction::setDebugLoc(), but that method doesn't

I am interested in using LLVM to translate C and C++ into high-level language code. (As an update to an earlier project of mine, Clue, which used the Sparse compiler library to do this: it targets Lua, Javascript, Perl 5, C, Java and Common Lisp, with a disturbing amount of success. See http://cluecc.sourceforge.net for details.) The obvious place to start on this is the C backend, except in

On 25/01/11 00:17, David A. Greene wrote: [...] > The rewrite is happening. I've got the skeleton of the codegen done, > but I have to get it to build before I can check it in. After that, > everyone can start adding patterns. Is the new C backend 'register' based, that is, generating lots of little statements operating on lots of variables, rather than producing the huge

Hello! I'm looking at "Overview of available features" here: http://llvm.org/docs/GarbageCollection.html#collector-algos and can't understand something. First, does table header mean that there are already some GC's implemented besides "shadow stack"? E.g. can I just use them? Second, does row "JIT", "NO" mean that GC is not compatible with