similar to: [LLVMdev] assumptions about varargs ABI

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

Hello! I've been trying to implement a simple compiler from Scheme to LLVM IR, and have run into the following problem: In Scheme, any function can be called on any number of arguments, but it should check at runtime for arity errors. I haven't been able to find a way in LLVM IR to access the actual number of parameters a function was called with. I think the following approach might

Hello, A new patch: https://reviews.llvm.org/D47159 proposes transformations like: printf("Hello, %s %d", "world", 123) - > printf("Hello world 123") As Eli noted: "I'm not sure we can rewrite calls to varargs functions safely in general given the current state of the C ABI rules in LLVM. Sometimes clang does weird things to conform with the ABI

On 05/22/2018 04:32 AM, Dávid Bolvanský via llvm-dev wrote: > Hello, > > A new patch: > https://reviews.llvm.org/D47159 > > proposes transformations like: > printf("Hello, %s %d", "world", 123) - > printf("Hello world 123") To clarify, the real question here comes up when you can only substitute some of the arguments? If you can substitute all

Thanks. Yes, to substitute only some of the arguments. Formatting used by printf depends on the locale but only for double, float types I think - yes, I would not place double/float constants into the format string. Why? To reduce number of constants (some of them could be merged into the format string) and number of args when calling printf/fprintf/sprintf, etc.. 2018-05-22 16:22 GMT+02:00 Hal

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 05/22/2018 10:42 AM, Dávid Bolvanský wrote: > Thanks. > > Yes, to substitute only some of the arguments. Formatting used by > printf depends on the locale but only for double, float types I think > - yes, I would not place double/float constants into the format string. Okay. I think it's true that integers will be the same regardless of locale (so long as the ' flag is

On 05/22/2018 11:59 AM, Dávid Bolvanský wrote: > It could save useless parsing in s/f/printf during runtime. Sure. But it is not clear that matters. printf is expensive anyway. Maybe this matters more for snprintf? Have you benchmarked this? > > E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I > think it could be quite useful.  > After

I need to insert a varargs function declaration from within an LLVM pass. getOrInsertFunction() allows an arbitrary list of type parameters for function arguments to be passed in, but as far as I can tell there is no LLVM "type" to represent the variable-length portion of a function argument list. How is this normally done? --Patrick

Do you compile this as C? In C, unlike in C++, empty parenthesis do not mean "no arguments", they mean "no prototype", which is typically treated the same way as varargs in calling conventions. To declare function with no arguments do typedef void (*FP)(void); Eugene On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Hi all, > >

On Tue, May 22, 2018 at 12:59 PM, Dávid Bolvanský via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It could save useless parsing in s/f/printf during runtime. > A mix of calls to puts and calls to printf with format strings containing just a conversion specifier can help towards such a goal without mutating constants beyond the format string. > > E.g. for heavy

Sometime this weekend (or today) vararg support will change. vanext will go away, and the intrinsic signatures will change. Backwards compatibility code will be included so front ends won't need to change initially (after that code is tested, then we will upgrade llvm-gcc). What should work after the transition: All Pattern based ISels (default on x86, PPC, Alpha, IA64) Existing .bc and .ll

Converting to puts is usually not possible: puts appends a newline to its output. The only really appropriate thing to convert to, that works in general, is fwrite. But we can't convert to that because we can't form the 'stdout' parameter (stdout might be a macro rather than a global, or might have a nontrivial mangling, so LLVM can't synthesize it). Also, converting

Hi all, I had the following function that used function pointers with void arguments, typedef void (*FP)(); void foo() { printf("hello world from foo\n"); } int main() { FP fp; fp = foo; (*fp)(); } The corresponding bitcode, with no optimizations is target datalayout =

It could save useless parsing in s/f/printf during runtime. E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I think it could be quite useful. After this transformation we would get fprintf(f, "ABC: %s", msg); --> We could save one push/mov instruction + less parsing in printf every time we call it. We would just replace string constant

> 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

When I use clang on an x86-64 to spit out the LLVM, like this clang -O -S -emit-llvm varargstest.c where varargstest.c looks like this int add_em_up(int count, ...) { va_list ap; int i, sum; va_start(ap, count); sum = 0; for (i = 0; i < count; i++) sum += va_arg(ap, int); va_end(ap); return sum; } I see LLVM that looks like it's been customized for the x86-64, versus

Hi, I'm looking at writing a custom backend targetting a proprietary virtual machine. I'm basing it on the existing C and MSIL backends. The VM has a defined ABI for varargs functions: the caller allocates some memory to hold the arguments and passes a pointer to this memory as an extra parameter in the call. I'd like to write a varargs lowering pass that represents this ABI

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