similar to: [LLVMdev] Scheme on LLVM IR

Hi Peter, > Are there any better ways to solve this? Does any of the existing > calling conventions support this? Can't you handle this entirely in the front-end? Just decide by fiat that all of your scheme functions will take an extra (hidden to the Scheme users) parameter saying how many args they were given. That's how C++ deals with the implicit "this" parameter for

> Can't you handle this entirely in the front-end? Just decide by fiat > that all of your scheme functions will take an extra (hidden to the > Scheme users) parameter saying how many args they were given. That's > how C++ deals with the implicit "this" parameter for class methods. > Then you could either use varargs or bitcast your functions to a > reasonable

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 Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with

On Apr 16, 2008, at 2:50 AM, heisenbug wrote: > > And now here is my educated speculation: > There are 2 things that became slower > 1) Use::getUser() > 2) Use::get/set due to tagging. > > The former is seldom called: > > $ find lib -name "*.cpp" | xargs grep "getUser(" | wc -l > 41 The majority of those aren't actually Use::getUser, but

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

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

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

Hi, I wanted to use wxSugar enumerable features to add a method for returning checked items'' index to the CheckListBox class : require ''wx_sugar/version'' require ''wx_sugar/wx_classes/control_with_items'' require ''wx_sugar/wx_classes/listctrl'' class Wx::CheckListBox def checked_items # use of find_all method from Enumerable

Specifying -no-implicit-float prevents LLVM from using non-GPR registers for purely integer operations. This is useful for operating systems (such as Wind River's VxWorks) that support tasks that do not save all registers on context switch. This presents an interesting problem for variadic functions that may optionally take non-integer arguments (e.g. printf style functions). Should non-GPR

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In

Such as printf, etc., from IR created using the API (IRBuilder). Google hasn't provided much help, and I can't find anything relevant in the docs (the docs talk about how to do varargs in LLVM ASM, but not how to call an external vararg function that exists in a library that gets linked to the LLVM module). Is there something special I need to do? Simply calling

Hi Gabor, Can you provide performance data for this? I'd like to know what affect these changes have on compile time. Thanks, Dan On Apr 15, 2008, at 3:32 PM, Gabor Greif wrote: > Hi All, > > here comes the patch for the second wave of Use class size reduction. > > I have included all the machinery that is needed, and it is > *active*. The User* inside of Use is even

I haven''t debugged this enough to understand what is happening, but I observe the following: someipset = bitmap:ip,mac 1) br0:+someipset 2) br0:+someipset[2] The first 1) doesn''t match anything in rules or tcrules, the second 2) matches fine. (Also using +someipset[1] doesn''t match anything) Is it possible/sensible/feasible to have shorewall figure out the

On 10/7/2013 3:23 PM, Nick Kledzik wrote: > On Oct 4, 2013, at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> 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 to have a varargs function in the

I've been out of touch with the LLVM community for a few years, and so I haven't kept up on all of the changes and improvements that have been added lately. I've been wondering if someone on this list would care to summarize what features of LLVM would be appropriate to expose as features of languages built on top of LLVM. In other words, if you were building a new LLVM-based language

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 to have a varargs function in the LinkingContext that would be overridden by each of the LinkingContexts to verify files after being read. The reader would call the varargs function in the LinkingContext and

Hi Dmitry, > Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug? it has nothing to do with flush - for all I know flush is fine. Dragonegg does this for all Fortran functions because the Fortran front-end is so buggy, i.e. often produces wrong function types. I have another way of handling this in mind, which would avoid this trick,

On Oct 4, 2013, at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > 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 to have a varargs function in the LinkingContext that would be overridden by each of the LinkingContexts to

On Wed, Oct 12, 2016 at 10:13 AM James Y Knight <jyknight at google.com> wrote: > > > I wonder what use cases you envision for this? Why does LLVM need a super > extensible flexible formatting library? I mean -- if you were developing > this as a standalone project, that seems like maybe a nice feature. But I > see no rationale as to why LLVM should include it. > We