[cir] [Lowering] Handle VaArg

[ChuanqiXu9]

I tried to reopen #865 but github get stucked..

---

After one month's deep experience with this patch, now I am more confident we need this patch.

For the long term, in the end of the day, we will need this since va_arg instruction is used in other targets in the traditional CodeGen pipeline. And in fact, the va_arg instruction lowering the default one in the traditional CG pipeline.

For the short term, this is still needed given we have non-robust X86 arguments classification today (See #1087). VAArg is pretty common in C codes. Without this, people who want to try clangir in the early days will meet the failures, this is pretty a bad experience.

For the maintaining concerns, since now we have #1086, we can add support more types after we make X86's arguments classification more stable. Like we did in #1087.

And it shows the code generated with va_arg is pretty good and LLVM will emit the error immediately if the LLVM can't handle it well.

[bcardosolopes]

Hey, thanks for making progress here.

... since va_arg instruction is used in other targets in the traditional CodeGen pipeline. And in fact, the va_arg instruction lowering the default one in the traditional CG pipeline.

If other targets use it and x86_64 doesn't, it means x86_64 is doing something special we probably want. If we go with the generic approach the motivations to match OG could wait forever, my take is that, if possible, we should target for de facto approach right away.

Without this, people who want to try clangir in the early days will meet the failures, this is pretty a bad experience.

IMO the bad experience should force the consumers to implement the OG approach, the incentives to work on the OG-like solution will diminish if we provide a working (non-optimal) path.

For the maintaining concerns, since now we have #1086, we can add support more types after we make X86's arguments classification more stable. Like we did in #1087. And it shows the code generated with va_arg is pretty good and LLVM will emit the error immediately if the LLVM can't handle it well.

I believe it's important to understand the differences first. Why OG x86_64 doesn't use va_arg? I'm assuming there's a good reason for this (sorry, I don't remember anymore). I propose that after #1086 and #1087 land, you create an issue explaining (a) why the status quo isn't robuts (as your mentioned in the previous paragraph), (b) whether/how that can be fixed and (c) re-evaluate whether we should just use va_arg in face of that and what are the steps to move away from it once someone is willing to do the work. The discussion in (c) should help us decide if we should use va_arg for x86_64.

How does this sound?

[ChuanqiXu9]

How does this sound?

Sounds good to me. And I'd like to write something down here when I have the context : )

I believe it's important to understand the differences first.

Yeah, understanding the underlying problem is great. And I searched https://discourse.llvm.org/t/rfc-the-future-of-the-va-arg-instruction/45908

it mentions:

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.

While these things, struct, integer registers, floating-point and memory are listed in #1086.

(a) why the status quo isn't robuts (as your mentioned in the previous paragraph)
(b) whether/how that can be fixed

To make this robust, we need a full X86_64 type classification. And also we need to be able to generate different vector types.

And I also want to mark that, va_arg instruction can't solve these things neither. It also has some "NYI" in the middle end. This is the reason why I was able to notice #1087

[bcardosolopes]

Thanks for pointing me to that discussion again :)

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.

This kinda confirms that we are probably better off not using va_arg, right? If the LLVM IR has lost that info while in CIR we still have it, probably best to lower in CIR and not use va_arg? It also seems reasonable that we could use va_arg for things that don't require struct, integer registers, floating-point and memory (as you mentioned for #1086) and have a somewhat mixed approach?

To make this robust, we need a full X86_64 type classification. And also we need to be able to generate different vector types. ... And also we need to be able to generate different vector types. ... And I also want to mark that, va_arg instruction can't solve these things neither

My understanding is that this can be done without any fundamental problem in CIR -> CIR, given we add all the bits. Trying to summarize the discussion: are you saying that we should use va_arg where possible until we can converge to full X86_64 type classification support?

[ChuanqiXu9]

This kinda confirms that we are probably better off not using va_arg, right?

Yes in the end of the day. And in fact, the design of clangir allows us to get rid of va_arg completely. As it is mentioned in the above thread:

In one of the many previous threads about ABI
lowering, I think someone commented that in LLVM it happens both too
early and too late (in the frontend, and on the SelectionDAG).

Frontend are too early and SelectionDAG are too late then clangir looks in the proper position : )

Trying to summarize the discussion: are you saying that we should use va_arg where possible until we can converge to full X86_64 type classification support?

Yes. And I feel va_arg is not so evil. It is pretty a tiny thing and it can assert itself when it finds the situation it can't handle. I completely understand your intention to try to make the generated code to be the same. But I feel va_arg won't be the devil here. It can help with user experience and developer experience in the early days.