similar to: [LLVMdev] lowering varargs, rewriting types

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

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

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

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

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

Hi, After discussion with Anton, I did the whole thing in a little bit different way (please see the attached patch). It again looks like reinvented wheel for LLVM experts, I suppose, but it works. What I want to achieve is to generate real (with all variadic arguments) call signature for each variadic and external function, without the "vararg" keyword and without the "...",

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. My VM only has 32- and 64-bit integer operations (like the JVM) but C code compiled with llvmgcc typically has lots of 1-, 8- and 16-bit instructions. I was thinking of writing a custom pass to promote small integer types and instructions to 32-bits,

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

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

Hi, This patch allows executing code with vararg pinvoke functions under Mono. It generates separate function declaration for each call signature. Artur -------------- next part -------------- A non-text attachment was scrubbed... Name: varargs.patch Type: text/x-patch Size: 5331 bytes Desc: not available URL:

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

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

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

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

I'm trying to use CallInst::Create to construct a call to a variadic function, and I'm running into the following assertion failure: /localhome/simmon12/workspace/llvm-sources/lib/VMCore/Instructions.cpp:297: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType())

Duncan, Oh, right, now I remember: it's a very old problem I knew 1.5 years ago. There were even some bugs on it, here is a common case: > cat test1.f90 program test call test1() end program test > kernelgen-dragonegg test1.f90 -o- | opt -O3 -S -o - ; ModuleID = '<stdin>' target datalayout =

Hello, I work in Kalray (Montbonnot, France) and I'm PhD student at Universite Joseph Fourier in Grenoble. We want to use LLVM framework for MSIL code generation, which is part of my thesis. Currently I'm still reading LLVM's documentation and I've started completing the MSIL backend for running on Mono. Things that need to be fixed include pointers initialization, call to