[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