search for: vaarg

...inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0, i32 3 %overflow_arg_area_p = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0, i32 2 %gp_offset.pre = load i32* %gp_offset_p, align 16 br label %for.body for.body: ; preds = %vaarg.end, % for.body.lr.ph %gp_offset = phi i32 [ %gp_offset.pre, %for.body.lr.ph ], [ %gp_offset10, %vaarg.end ] %sum.09 = phi i32 [ 0, %for.body.lr.ph ], [ %add, %vaarg.end ] %i.08 = phi i32 [ 0, %for.body.lr.ph ], [ %inc, %vaarg.end ] %fits_in_gp = icmp ult i32 %gp_offset, 41 br i1 %fits_in...

...has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand); I thought that I could solve this problem by: setOperationAction(ISD::VAARG, MVT::i1, Promote); AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); setOperationAction(ISD::VAARG, MVT::i8, Promote); AddPromotedToType (ISD::VAARG, MVT::i8, MVT::i64);...

...pes smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended to 64 bits on the stack and the default logic > > provided in LegalizeDAG does not use that convention. Specifically, > > for these targets we have: setOperationAction(ISD::VAARG, > > MVT::Other, Expand); I thought that I could solve this problem by: > > setOperationAction(ISD::VAARG, MVT::i1, Promote); > > AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); > > setOperationAction(ISD::VAARG, MVT::i8, Promote); > > Ad...

...than 64 bits. >>> This is because the ABI specifies that these types are >>> zero-extended to 64 bits on the stack and the default logic >>> provided in LegalizeDAG does not use that convention. Specifically, >>> for these targets we have: setOperationAction(ISD::VAARG, >>> MVT::Other, Expand); I thought that I could solve this problem by: >>> setOperationAction(ISD::VAARG, MVT::i1, Promote); >>> AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); >>> setOperationAction(ISD::VAARG, MVT::i8, Promote); >...

...ng integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for these targets we have: > setOperationAction(ISD::VAARG, MVT::Other, Expand); > I thought that I could solve this problem by: > setOperationAction(ISD::VAARG, MVT::i1, Promote); > AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); > setOperationAction(ISD::VAARG, MVT::i8, Promote); > AddPromotedToType (ISD::VAA...

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 ap) { int idx = ap->gpr; if (idx < 8) { ap->gpr = idx + 1; return ap->reg_save_area[idx]; } else { int res = ap->overflow_arg_area[0];...

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

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 box &...

...meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, > So I write a phi case, it like > ___________________________________________________ > vaarg.end: ; preds = %vaarg.in_mem, %vaarg.in_reg > %5 = phi i32 [ %4, %vaarg.in_reg ], [ %l5, %vaarg.in_mem ], !dbg !50 > %6 = add nsw i32 %gp_offset, %vaarg.l, !dbg !41 > call void @llvm.dbg.value(metadata i32 %5, metadata !28, metadata !DIExpressio...

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 = "e-p:32:32:32-i...

Hi, After several months of procrastination I'm at the point where I'd like to implement vaargs in all the code generators that do not support it yet. As a little background, I'm putting together a version of newlib, startup code, linker command files, soft-flt (if needed), and compiler-rt that I'm building for the llvm targets supported by qemu. I build programs and run them in...

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 behavior to the new behavior. However, converting from the current behavior to the old behavior is very non-trivial. Is bytecode compatibility for...

...is requires > the frontend to know the abi of the backend. Even with an intrinsic > for allocating a va_list, you have the problem of what type should be > returned. > We can set the type of the va_list to be i8* or i8**. Even if internally it's something else. > Right now, vaarg > handling is not target independent at the llvm level. Isn't this an error at the conception level? llvm bytecode should be target independent. > I agree that a > va_list alloc intrinsic would go a long way towards abstracting the > target ABI from a vaarg function. > >...

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: ; Mod...

...Assuming people have 1.1 (and removing the code for dealing with 1.0) or later should be no problem for the LLVM 1.5 release. If you make this change, please add a note to the release notes. > 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 behavior to the new behavior. > However, converting from the current behavior to the old behavior is > very non-trivial. > > Is...

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

...intrinsic for declaring a va_list. This > unfortunately requires changes to all > backends, but i do not see how this can be handled differently. If an other backend already handles this correctly, please > tell me which one. No, the problem is just updating all the frontends. Right now, vaarg handling is not target independent at the llvm level. I agree that a va_list alloc intrinsic would go a long way towards abstracting the target ABI from a vaarg function. Andrew

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 is OK for x86 and PPC/Darwin ABI because a va_list in these architectures is just a pointer to the stack. The va_start intrinsic just initializes where the pointer points at in the stack. I do not know how the other backends operate, but I

FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg flag to Clang. Applies against mainline. (As discussed, va_arg isn't really supported well so this probably doesn't work well on anything other than simple code, YMMV, etc) ~Will On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Have these chan...

...uld be necessary in the same cases casting is required for named args * Support for aggregates could be implemented via a new module-level pass, much like PNaCl. * Alternatively, the conversion from the va_arg instruction to SelectionDAG could be modified. It might be desirable to convert the vaarg instruction to a number of loads and a new node that is responsible only for manipulating the va_list struct. Option 4: Expect va_arg to handle all ABI details * In this more extreme option, va_arg with any type would expected to generate ABI-compliant code. e.g. a va_arg with i128 would &...