[llvm-dev] [RFC] The future of the va_arg instruction

[Alex Bradbury via llvm-dev]

On 9 August 2017 at 19:38, Friedman, Eli <efriedma at codeaurora.org> wrote:
> 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.

If converting va_arg {i8, i8} to two va_arg i8, you'd ideally ensure
this results loading the two i8 values from the same slot in the
vararg save area. Of course when passing structs direct for named
arguments, we currently rely on the frontend coercing structs for
cases like this. As such, the naive conversion shouldn't be any worse
than the status quo for named arguments.

Best,

Alex