llvm dev - Apr 2007 - [LLVMdev] Declaration of a va_list should be an intrinsic?

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 suppose it's the same.

However, on the PPC/ELF ABI, a va_list is a struct (referring to
http://refspecs.freestandards.org/elf/elfspec_ppc.pdf)
of 12 bytes allocated on stack. The struct *should* not be allocated by va_start
because a va_copy would not know
if the struct is allocated or not.

Therefore, I think there should be a special 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.

For X86 and PPC/Darwin (and others), the intrinsic will do:
alloca i8*

And for PPC/ELF it does:
alloca [12 * i8]

Does this sound correct?

Best,
Nicolas

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 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.
> Therefore, I think there should be a special 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 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} (and
> does so in llvm-gcc).  What the type of the alloca to use 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.
>
>   
So you agree that it's the correct way to implement this target-dependant
feature? Updating all backends shouldn't be too hard.

Cheers,
Nicolas