similar to: [LLVMdev] Extracting all BasicBlocks of a Function into new Function

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, Op 2-okt-06, om 21:35 heeft Chris Lattner het volgende geschreven: > I think the easiest way to do this is to do the 'complement' as you > describe, but specially handle the varargs case. Basically you > need to > call va_start in the original function, and pass the valist pointer > down. > This shouldn't be too hard. OK. I've been rethinking my use

Hi, Chris Lattner wrote: > All the non-vastart calls can be anywhere. va_end in particular codegens > to a noop on all targets llvm currently supports, fwiw. > Things go well, except for the following (pathological?) C program: int va_double_sum(int count,...){ int i,sum=0; va_list ap; va_start(ap,count); for(i=0;i<count;i++){ sum+=va_arg(ap,int); } va_end(ap);

Hi, Op 3-okt-06, om 20:48 heeft Chris Lattner het volgende geschreven: > You'd have to change it to something like: > > void foo(int X, ...) { > P = va_start(); > bar(X, P); > } > > void bar(int X, valist P) { > use(P); > } Can the other va_...-intrinsics be used in bar as were the "P = va_start" in bar? The va_start probably is unnecessary

On Mon, 2 Oct 2006, Bram Adams wrote: > So, I wonder what problems may show up in this algorithm (steps 4, 5 > and 6 seem to be crucial). The vararg-case could be a problem in step > 5, although the va_start intrinsic isn't tied to the surrounding > Function at first sight. There is an implicit dependency between vastart and the function it lives in. Specifically, if you have:

On Thu, 5 Oct 2006, Bram Adams wrote: > Apparently, the problem is how to "rewind" the vararg-argument back to > its first element when the second loop is reached, as it seems that the > code just continues at position count and beyond, resulting in overflow. > > I'm not sure whether this code snippet is valid ANSI C, and if it is, > one probably shouldn't use

On Tue, 3 Oct 2006, Bram Adams wrote: >> You'd have to change it to something like: >> void foo(int X, ...) { >> P = va_start(); >> bar(X, P); >> } >> >> void bar(int X, valist P) { >> use(P); >> } > > Can the other va_...-intrinsics be used in bar as were the "P = > va_start" in bar? The va_start probably is

Hi, Op 5-okt-06, om 16:05 heeft Ryan Brown het volgende geschreven: > I don't know if that's valid but what about something like this: > int va_double_sum(int count,...){ > /*declare va_list for each original va_start*/ > /*llvm.va_start for each va_list*/ > /*call extracted_sum(count,va_list1, va_list2, ...)*/ > } That should work, I think, ... Op 5-okt-06, om

Hi, Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: > Anton is right. You should be able to use -fno-builtins to disable > this. Thanks, that did the trick. Some final remarks (my app works again :-)): * llvm.va_start and similar intrinsics now have an i8* arg instead of an sbyte** * For some reason the Arguments of a Function are now circularly linked,

It looks like something got broken in openbsd-compat/bsd-snprintf.c ... gcc -g -O2 -Wall -Dftruncate=chsize -I/usr/local/include -I/usr/local/ssl/includ e -I. -I.. -I../src/openbsd-compat -I../src/openbsd-compat/.. -DHAVE_CONFIG_H -c ../src/openbsd-compat/bsd-snprintf.c In file included from ../src/openbsd-compat/bsd-snprintf.c:72:

LLVMers, And while we're on the subject to the type definitions table, what's the difference between 0e 07 01 00 function returning Int ( Void )? Function returning Int ( ... )? and 0e 07 00 Function returning Int () I'm guessing the former really is a function returning Int ( ... ), but how is the callee supposed to decode the parameter list? I'm an old callee and I

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

Hello, Bram > * It seems that a C-call like printf("---\n") is transformed to puts > ("---") in the LLVM IR instead of keeping it a printf. What are the > circumstances in which this happens? Do other similar conversions > occur? Can this be turned off (lower optimisation level?)? Manually > replacing the puts-calls by a printf-call is not

Hello again! We have fetched the latest llvm sources from repository and the original problem has went away. Though now we are facing a new problem with interpreter on the following c code: -------------- #include <stdarg.h> #include <stdio.h> void doTheThing(int dummy, ...) { va_list ap; int z; va_start(ap, dummy); while( (z = va_arg(ap, int))!=0) { printf("==

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

On Sat, 19 May 2007, Anton Korobeynikov wrote: >> * It seems that a C-call like printf("---\n") is transformed to puts >> ("---") in the LLVM IR instead of keeping it a printf. What are the >> circumstances in which this happens? Do other similar conversions >> occur? Can this be turned off (lower optimisation level?)? Manually >> replacing the

I'm wonder if anyone happens to have a simplier (slower) version of bsd-snprintf.c. It seems NeXT 3.3 (unsure about 4.2) is missing mprotect(). If I could get something to replace that for a while and fix some of theses utmp in login.c issues I may have a rough port NeXT to black hardware.=) Thanks

On 02/01/2010 01:13 PM, Kristaps Straupe wrote: > Hello again! > > We have fetched the latest llvm sources from repository and the > original problem has went away. Though now we are facing a new problem > with interpreter on the following c code: > > -------------- > #include <stdarg.h> > #include <stdio.h> > > void doTheThing(int dummy, ...) > {

Hi, Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven: > I looked over your patch and it looks good. I applied a patch based on > yours. The llvm-ld tool now uses the PluginLoader just like the opt > tool. It will also run some cleanup passes after the loaded plugins > run > to ensure cruft is removed. OK, thanks. Your patch seems to work, although I also get

Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in