[LLVMdev] Is va_arg deprecated?

[Will Dietz]

Oh, sorry about that, and thanks for the clarification as to what you
were looking for.

Here you go:

** Why do we want this option? **

Presently clang will manually lower va_arg() in the frontend to the
equivalent (relatively complicated!) IR, as opposed to making use of
the LLVM va_arg instruction directly.  IR that contains the va_arg
instruction is much easier to analyze because it is concise and clear
in its semantics.  The lowered version IR is target-specific pointer
manipulation from a magic struct, that can expand to multiple BB's and
introduce conditional branches.  Therefore, this option helps make the
IR significantly easier to analyze and is probably also rather useful
for source-to-source transformations.

** Do we want it on all the time? Why or why not? **

No, certainly not.  Not until the various backends fully support the
va_arg instruction*, and even then there might be ABI issues**.
Furthermore, the existing clang code seems to suggest emitting va_arg
instructions for complex and aggregate values doesn't work***, and my
limited testing agrees with this.  It's also possible that lowering it
later rather than earlier has an effect on optimizations and the like,
but I don't know how significant that is.

For those reasons I'd say this option should default to off (as done
in the patch), as va_arg doesn't seem suitable for general use at this
time.

**************
Attached is updated version of the patch that gives a neat unsupported
error (same code path as when the target doesn't implement EmitVAArg)
when attempting to emit va_arg instruction for complex or aggregate
types, instead of an ugly assertion failure.

Let me know if you have any further comments or questions, I'm happy
to help as I can.

Thanks!

~Will

* = See http://llvm.org/bugs/show_bug.cgi?id=1740 and related
** = http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007799.html
*** = Not the best reference, but
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007784.html
shows the relevant code, and as mentioned my testing shows these
unsupported errors are for good reason (surprise!).

On Wed, Aug 17, 2011 at 5:08 PM, Eric Christopher <echristo at apple.com> wrote:
> I should have been more specific:
>
> "Why do we want this as an option? Do we want it on all the time? Why or why not?"
>
> -eric
>
> On Aug 17, 2011, at 3:02 PM, Will Dietz wrote:
>
>> To get clang to emit va_arg instructions for va_arg() calls, as
>> opposed to manually lowering it in the frontend, same as the llvm-gcc
>> patch sent earlier does.
>>
>> ~Will
>>
>> On Wed, Aug 17, 2011 at 2:41 PM, Eric Christopher <echristo at apple.com> wrote:
>>>
>>> On Aug 17, 2011, at 11:53 AM, Will Dietz wrote:
>>>
>>>> FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg
>>>> flag to Clang.
>>>>
>>>> Applies against mainline.
>>>>
>>>> (As discussed, va_arg isn't really supported well so this probably
>>>> doesn't work well on anything other than simple code, YMMV, etc)
>>>>
>>>> ~Will
>>>>
>>>> On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:
>>>>> Have these changes made it to mainline? Is there a way to get a patch for the
>>>>> backend, which does the actual lowering?
>>>>>
>>>>> Thanks,
>>>>> Arushi
>>>>>
>>>>> On Sun, Feb 20, 2011 at 1:54 PM, David Meyer <pdox at google.com> wrote:
>>>>>> Sergey,
>>>>>> Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg".
>>>>>> (Note that this patch won't ever be part of llvm-gcc upstream. It will most
>>>>>> likely be deprecated by later changes.)
>>>>>> - pdox
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>
>>>> <0001-Add-option-to-force-emitting-va_arg-instruction.patch>_______________________________________________
>>>
>>> So, what's the point of this one?
>>>
>>> -eric
>>>
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-option-to-force-emitting-va_arg-instruction.patch
Type: application/octet-stream
Size: 6027 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110818/2483bebb/attachment.obj>