put the va_list implementation from clang to llvm

[mttbx]

Proposal. To make variable param function work. Put the va_list implementation into the llvm. So that other language can utilize it.

[nhaehnle]

It is already in LLVM, please see https://llvm.org/docs/LangRef.html#variable-argument-handling-intrinsics for the relevant documentation.

Please re-open with a clarification if you mean something more specific.

[mttbx]

@nhaehnle The definition of va_list is not provided by llvm. What I mean is to put the definition of va_list from clang to llvm.
Notice that the definition of va_list in the example below is hand writen. As a matter of fact, I can't define va_list arbitrary. So If I want to implement variable-argument-function, I have to find out what is the difinition of va_list of the target. I noticed that clang implement that, so I suggest to put these code from clang to llvm. So that other language can be benifit.

; This struct is different for every platform. For most platforms,
; it is merely a ptr.
%struct.va_list = type { ptr }

; For Unix x86_64 platforms, va_list is the following struct:
; %struct.va_list = type { i32, i32, ptr, ptr }

[nhaehnle]

Thanks for clarifying. I agree that that seems useful if it hasn't already been done. Seems like a good idea to me, and something you could probably just do?

[mttbx]

Right now I just know a little of the framework of the llvm implementation. I'm wandering if somebody more familiar with clang could do it. It would be time-saving. If I implement it, it maybe not good. Thank you for reopening this issue : )

[nhaehnle]

Realistically speaking, nobody else is going to pick this up for you. I agree that it can be tough to find your way in the code base. And sure, your first cut may not be good, but that's what the code review process is for.

The implementation of va_list is clearly a function of the target, so it feels like the kind of information that should probably be exposed via a TargetTransformInfo method.

[jsonn]

LLVM itself has only a very rudimentary implementation of va_list and that's for a good reason. While some platforms have very simple rules for argument passing ("Everything goes on the stack"), others have very complex rules for using registers for the first few arguments and different registers based on size and type (e.g. general purpose vs floating point registers). Historic discussions on this topic basically questioned how well this can be abstracted without reimplementing a significant part of the C type system.

[mttbx]

@jsonn Where is the discuss? Could I see it? What I thought before was just to define a struct for different target.

[wareya]

I ran into this while trying to add support for vararg FFI to my toy programming language.
LLVM has a function to get the pointer-sized int type and generally abstracts away the C ABI wherever it's reasonable to do so; why not here? The way the example code under Variable Argument Handling Intrinsics is written, it looks like va_list is going to be a particular sized type on any given platform, so it should be as simple as having a function to return the correct type somewhere. And if it's not that simple, then that section of the manual is wrong or highly misleading.

[mttbx]

@wareya I agree. This is an important functionality. And it should be implemented by llvm not clang.

[nhaehnle]

I'll try to help review any patches you may have.