[LLVMdev] Is va_arg deprecated?

[Renato Golin]

On 18 August 2011 06:13, Will Dietz <willdtz at gmail.com> wrote:
> 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.

Hi Will,

I think that was a great summary. There is, however, one question that
is hovering this issue:

If not all back-ends support, and we don't want it all the time, is it
worth to keep it half-way through just for the sake of simplicity in
some analysis?

Other features (like union types) got removed for the same reason, and
as much as I liked the idea of having them, I didn't have a strong
case to keep them in the trunk.

To have a flag that will enable it only in special cases is the
quickest way to decommission in the near future, especially near major
releases (like 3.0).

There is a way to work around it that was touched last year when we
were discussing about union types, bitfields and C++ ABI: to have an
IR lowering pass.

The idea is that front-ends can create a reasonably simple IR by using
special constructs (va_arg, bitfield semantics, union types) but not
all back-ends can understand them and, most importantly, those that
do, do it at different levels. So, this pass could be run after all
the passes that need the extra semantics, (lowering all constructs
into simpler, messier IR), and before the other passes that need the
lower IR. Specific targets could have special lowering passes, if
there is a feature they don't support.

For example, at that time, the ARM back-end couldn't deal with struct
by-val, but it could with array by-val. So Clang had to cast all
structures being returned to arrays to pass it by-val. Now that is a
complication that Clang didn't have to know! So, to completely
de-couple front-ends from back-ends, we need those smart passes in the
middle-end.

But that's a long road...

cheers,
--renato