similar to: [LLVMdev] Perfect forwarding?

Blast! LLVM mailing server *still* has the headers broken... On Mon, Aug 31, 2009 at 11:03 PM, Talin<viridia at gmail.com> wrote: > OvermindDL1 wrote: >> >> BLAST! LLVM mailing list headers are still royally screwed up... >> My message is below... >> >> On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote: >> >>>

BLAST! LLVM mailing list headers are still royally screwed up... My message is below... On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote: > Hey all, it's been a while since I have posted on this list, but I've > been continuing my work with LLVM and getting lots done :) > > One question I wanted to ask is whether anyone had any advice on how to >

I needed this functionality to solve http://llvm.org/PR20653, but it obviously has far more general applications. You can do it like this: define i32 @my_forwarding_thunk(i32 %arg1, i8* %arg2, ...) { ... ; define new_arg1 and new_arg2 %r = musttail call i32 (i32, i8*, ...)* @the_true_target(i32 %new_arg1, i8* %new_arg2, ...) ret i32 %r } declare i32 @the_true_target(i32, i8*, ...) The

On 8 Oct 2014, at 18:19, Reid Kleckner <rnk at google.com> wrote: > The one target I know about where varargs are passed differently from normal arguments is aarch64-apple-ios/macosx. After thinking a bit more, I think this forwarding thunk representation works fine even on that target. Typically a forwarding thunk is called indirectly, or at least through a bitcast, so the LLVM IR call

On Sun, 1 Oct 2006, Bram Adams wrote: > One of the obstacles I face when trying to do the complement > (creating new Function and adding call to original in it), is to find > out how to pass the varargs argument of the new Function into the > call to the old Function. Will passing the sbyte** passed to > llvm.va_start do the trick? I think this is the better way to go. If

Hi, I need to find a way to extract all BasicBlocks of a Function (no clones!) into a new Function that has the exact same signature, and adding a call to the new Function in the old one. I tried out lib/ Transforms/Utils/CodeExtractor::ExtractCodeRegion(...), but this one unfortunately checks first to see whether there are any allocas and/ or va_starts and returns a null pointer in that

On Thu, Jul 14, 2011 at 9:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > Hi llvm-dev! > > I have attached the current state of my GSoC work in patches [1] for > review; this currently allows LLVM to correctly handle functions running > out of stack space and variable sized stack objects. > > Firstly, since I think it is better to get things merged in

Hi llvm-dev! I have attached the current state of my GSoC work in patches [1] for review; this currently allows LLVM to correctly handle functions running out of stack space and variable sized stack objects. Firstly, since I think it is better to get things merged in small chunks, I'd like to have some specific feedback on where my work stands in terms of mergeability. Secondly, I had been

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

On Fri, Oct 25, 2013 at 8:35 PM, Philip Reames <listmail at philipreames.com>wrote: > On 10/25/13 1:10 PM, Ben Karel wrote: > > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com>wrote: > >> Hi Rafael, Andrew, >> >> Thank you for the prompt reply. >> >> One approach we've been considering involves

On 10/25/13 1:10 PM, Ben Karel wrote: > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com > <mailto:sanjoy at azulsystems.com>> wrote: > > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects

Hi, Various parts of LLVM seem to assume that the ABI for a varargs function is compatible with the ABI for a non-varargs function, so that code like this: define void @f(i32 %x) { ... } ... call void (...)* bitcast (void (i32)* @f to void (...)*)(i32 42) will work. (I don't think C guarantees that this will work, at least not in the version of the C99 standard I checked.) I'm

Thanks for responding, Duncan, and clarifying that y'all need more info to help. I'm trying to compile binaries on os x 10.5.8 intel hardware that are compatible on ppc os x 10.4. When I include various flags to llvm-gcc, including: -m32 -arch ppc -isysroot /Developer/SDKs/MacOS10.4u.sdk -mmacosx-version-min=10.4 I am seeing errors when compiling using llvm-gcc 4.2. If I leave out

Hi Eli, > That said, clang really should be turning int x2() { return x(0); } > into "define i32 @x2()" rather than "define i32 @x2(...)"; the > function isn't varargs, and marking it as such could lead to wrong > code for exotic calling conventions. I always understood that this is correct per C language specification. For functions that are internal (static),

On Thu, 13 Sep 2007, Jay Foad wrote: > Various parts of LLVM seem to assume that the ABI for a varargs > function is compatible with the ABI for a non-varargs function, so This is due to 'K&R' C function handling. In K&R and ANSI C, you can do stuff like this: void foo(); void bar() { foo(1, 2, 3); } void foo(int a, int b, int c) {} and it needs to work. > (I

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

----- Original Message ---- > From: Kenneth Uildriks <kennethuil at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 12:22:55 PM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > >

Gah, headers not set appropriately, message I sent is forwarded below (it still takes a good extra 45-90 seconds to change the "To" line on this device...): On Thu, Sep 3, 2009 at 2:45 AM, Talin<viridia at gmail.com> wrote: > OvermindDL1 wrote: >> >> Boost.Fusion has adapters to convert structs/classes into >> tuples/kwtuples. You have to write the short and

On 10/4/2013 11:16 PM, Michael Spencer wrote: > On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Hi, >> >> It is needed that lld verifies the input to the linker. >> >> For example : a x86 ELF file can be given to lld when the target is >> x86_64. Similiarly with other flavors. >> >> I was thinking

On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow <samuraileumas at yahoo.com> wrote: > > > > > ----- Original Message ---- >> From: Kenneth Uildriks <kennethuil at gmail.com> >> To: Samuel Crow <samuraileumas at yahoo.com> >> Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Sent: