similar to: [LLVMdev] Line number information (and other metadata)

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

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

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

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

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

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

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

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

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

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

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