search for: valist

...ow 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 you're concerned about varargs, you need to call va_start in the varargs one, then pass the valist down. I thin kthe 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. -Chris -- http://nondot.org/sabr...

Hi, I need to find a way to extract all BasicBlocks of a Function (no clones!) into a new Function that has the exact same signature, and adding a call to the new Function in the old one. I tried out lib/ Transforms/Utils/CodeExtractor::ExtractCodeRegion(...), but this one unfortunately checks first to see whether there are any allocas and/ or va_starts and returns a null pointer in that

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 of lib/Transforms/Utils/ CodeExtractor::ExtractCodeRegion(...) to obtain my first goal, but I don't think I need such a complex algorithm after all. Basically, I only need to clone a Function...

...d foo(int X, ...) { P = va_start(); use(P); } You can't change this to: void foo(int X, ...) { bar(X); } void bar(int X, ...) { P = va_start(); use(P); } 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); } -Chris -- http://nondot.org/sabre/ http://llvm.org/

...ues 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 this approach, but I'm just curious to know > how (and if) this problem could be solved. Why not va_copy the input valist? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...,...){ > /*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 20:51 heeft Chris Lattner het volgende geschreven: > Why not va_copy the input valist? ... and so would this. The only problem left is that both require an easy way to replace each use of the original va_list situated AFTER a (to be removed) va_end with the second va_list. This seems a task for a control flow graph based function checking the (possibly partial) order betwee...

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 now in bar, but where dus the va_end need to be: at the end of foo or of bar or doesn't it matter? Thanks for the remark, Bram Ad...

...956,8 @@ > tree gpr, fpr, ovf, sav, t; > > /* Only 64bit target needs something special. */ > - if (!TARGET_64BIT) > + /* LLVM also uses the i386 standard version in 64-bit mode */ > + if (!TARGET_64BIT || EMIT_LLVM) > { > std_expand_builtin_va_start (valist, nextarg); > return; > @@ -3015,7 +3024,8 @@ > int indirect_p = 0; > > /* Only 64bit target needs something special. */ > - if (!TARGET_64BIT) > + /* LLVM also uses the i386 standard version in 64-bit mode */ > + if (!TARGET_64BIT || EMIT_LLVM) > {...

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

On alpha, I am seeing a problem with Emiting va_copy.  valists are structs and allocated by alloca, unlike x86.  EmitBuiltinVACopy is therefore using the second branch of the if (~llvm-convert.cpp:6538) to emit the second argument.  The second argument is the result of an alloca.  TreeToLLVM::Emit is hitting the first assertion (~929). The exp being passed i...

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 unnecessary now in bar, > but where dus the va_end need to be: at the end of foo or of bar or > doesn't it matter? All t...

...ed type of @object + * @result: pointer to variable taking cast result of @object + * @argc: count of arguments passed to the function + * @argv: arguments passed to the function + * @args: argument conversion string + * @varargs: pointers to variables taking converted arguments + * + * This is the valist version of swfdec_as_native_function_check(). See that + * function for details. + * + * Returns: %TRUE if the conversion succeeded, %FALSE otherwise + **/ +gboolean +swfdec_as_native_function_checkv (SwfdecAsContext *cx, SwfdecAsObject *object, + GType type, gpointer *result, guint argc, Swfde...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...OperationAction(ISD::VAARG, VT) == TargetLowering::Custom) { - Tmp3 = DAG.getVAArg(VT, dl, Tmp1, Tmp2, Node->getOperand(2)); - Result = TLI.LowerOperation(Tmp3, DAG); - } else { - const Value *V = cast<SrcValueSDNode>(Node->getOperand(2))->getValue(); - SDValue VAList = DAG.getLoad(TLI.getPointerTy(), dl, Tmp1, Tmp2, V, 0); - // Increment the pointer, VAList, to the next vaarg - Tmp3 = DAG.getNode(ISD::ADD, dl, TLI.getPointerTy(), VAList, - DAG.getConstant(VT.getSizeInBits()/8, - TLI.getPo...