[llvm-dev] [RFC] The future of the va_arg instruction
Friedman, Eli via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 9 11:38:18 PDT 2017
On 8/9/2017 9:11 AM, Alex Bradbury via llvm-dev wrote:
> Option 3: Teach va_arg to handle aggregates
> * In this option, va_arg might reasonably be expected to handle a struct,
> but would not be expected to have detailed ABI-specific knowledge. e.g. it
> won't automagically know whether a value of a certain size/type is passed
> indirectly or not. In a sense, this would put support for aggregates passed
> as varargs on par with aggregates passed in named arguments.
> * Casting would 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.
We could automatically split va_arg on an LLVM struct type into a series
of va_arg calls for each of the elements of the struct. Not sure that
actually helps anyone much, though.
Anything more requires full type information, which isn't currently
encoded into IR; for example, on x86-64, to properly lower va_arg on a
struct, you need to figure out whether the struct would be passed in
integer registers, floating-point registers, or memory.
> ## Next steps
> I'd really appreciate any input on the issues here. Do people have strong
> feelings about the future direction of va_arg? Will GlobalISel have any effect
> on the relative difficulty or desirability of these options?
>
For GlobalISel, the important bit is the mostly orthogonal question of
*when* we lower va_arg. If we do it sometime before isel, we save a bit
of implementation work.
-Eli
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the llvm-dev
mailing list