similar to: [LLVMdev] Declaration of a va_list should be an intrinsic?

On 4/2/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Hi everyone, > > Currently, when declaring a va_list in llvm, one only needs to do: > > %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) This example is x86 specific. alpha allocas an {sbyte*, int} (and does so in llvm-gcc). What the type of the alloca to use is requires the frontend to

Hi Andrew, Andrew Lenharth wrote: > On 4/2/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > >> Hi everyone, >> >> Currently, when declaring a va_list in llvm, one only needs to do: >> >> %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) >> > > This example is x86 specific. alpha allocas an {sbyte*, int}

Hi everyone, I'm implementing varags handling for PPC32 with the ELF ABI. It is largely more complicated than the Macho ABI or x86 because it manipulates a struct instead of a direct pointer in the stack. You can find the layout of the va_list struct at the end of this mail. A VAARG call requires a lot of computation. Typically the C code for va_arg(ap, int) is: int va_arg_gpr(ap_list

On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > A VAARG call requires a lot of computation. Typically the C code for > va_arg(ap, int) If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? -Chris > is: > > int va_arg_gpr(ap_list ap) { > int idx = ap->gpr; > if (idx < 8) { > ap->gpr = idx + 1; > return

Hi Chris, Chris Lattner wrote: > On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > >> A VAARG call requires a lot of computation. Typically the C code for >> va_arg(ap, int) >> > > If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? > I'm guessing that if you're asking, then no llvm.vaarg is generated. I can not test it on my

Hi Jim, I didn't use any documents, but intensively looked at gcc's output. I think this document: http://refspecs.freestandards.org/elf/elfspec_ppc.pdf is the last specification of the ABI. Cheers, Nicolas Jim Laskey wrote: > Nicolas, > > Would you point me to the Linux/PPC ABI documents you are using so I > can better judge what your restrictions are? These changes

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to transition all targets and LLVM frontends to using it? ## Background on va_arg

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

On 9 August 2017 at 19:38, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/9/2017 9:11 AM, Alex Bradbury via llvm-dev wrote: >> >> Option 3: Teach va_arg to handle aggregates >> * In this option, va_arg might reasonably be expected to handle a >> struct, >> but would not be expected to have detailed ABI-specific knowledge. e.g. >> it

So Alpha and some other potential targets (amd64?) use structs for va_list. This is very much at odds with the current instructions and intrinsics. So the question for the community is how much backwards compatibility should be maintained for vaargs? Essentially the behavior needs to be reverted to LLVM 1.0 semantics for vaarg instructions. Currently there is conversion code to convert the old

Full_Name: Albrecht Gebhardt Version: 0.99.0 OS: alpha, osf4.0 Submission from: (NULL) (143.205.180.40) Both DEC cc and gcc complain (osf4.0, alpha) about applying an unary operator (!) to a non scalar type (va_list arg) in printutils.c I'm not sure if I understood what was intended by "!arg" (see below), but with this patch I at least was able to compile. (and R runs now, but I

Hi folk, I'm writing a set of small C code to verify whether my pass handle some instruction correctly. One of the instruction I want to test is "va_arg", but compiling my variadic function does not generate any va_arg instruction. Is va_arg deprecated? Will va_arg instruction ever be generated by any front-end? The source code and llvm instructions are appended as follows. the

I'm generating code for a target that only supports i32 natively. My front end is generating VAARG for accessing varargs parameters. The problem is that I get an assert when I compile this: #include <stdarg.h> int main(va_list ap) { typedef double type; type tmp; tmp = va_arg(ap, type); } Bitcode: ; ModuleID = 't0056.bc' target datalayout =

Hello, Everyone > On this specific case, IIRC, MinGW chokes if asmprinter is not on the > list of components. This may be another consequence of the malfunctoning > of llvm-config/GenLibDeps.pl on MinGW/MSYS. This works for me without any problems on mingw32. What are the problems you're seeing? -- WBR, Anton Korobeynikov

Neal, FYI, my group has added a flag to llvm-gcc for emitting the va_arg instruction (instead of lowering in the front-end), and we also have an implementation of the VAARG instruction for X86-64. (which is currently not implemented in the LLVM backend). Both of these things will be sent upstream to LLVM soon, pending some more testing and review. If you are dire need of these features now, I

hello, i got this error when i run make after downloading asteirsk from cvs. gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g -Iinclude -I../include -Iinclude/solaris-compat -I/usr/local/ssl/include -D_REENTRANT -D_GNU_SOURCE -O6 -Wcast-align -DSOLARIS -DBUSYDETECT_MARTIN -fomit-frame-pointer -c -o term.o term.c In file included from

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Hello, LLVMers! How can I force a front end to generate VAARG for accessing varargs parameters? I compile a simple C-code: #include <stdarg.h> int FnVarArgs(int a, ...) { int i,tmp=0; va_list ptArgument; va_start(ptArgument,a); for(i=0;i<9;i++) tmp+= va_arg(ptArgument,int); return tmp; } And then have this bytecode: ; ModuleID = 'main.bc' target

This might shed some light on the va_list problem reported previously. -d David Hesprich wrote: > > On Wed, 8 Mar 2000, Damien Miller wrote: > > > > log.c: In function `fatal': > > > log.c:17: `__builtin_va_alist' undeclared (first use in this function) > > > > A few people have reported this - it looks like a gcc vs native cc > > problem.

Hi, I'm trying to write some forward constant propagation of sprintf and friends, and I need a way to construct a (build) va_list from the IR of a variadic function so that I can evaluate it at build time. I can't find a standard way of doing this. -- --- Shawn Landden +1 360 389 3001 (SMS preferred)