[llvm] r295716 - [ARM] GlobalISel: Lower calls to void() functions

Tim Northover via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 21 07:40:16 PST 2017


Hi Diana,

On 21 February 2017 at 03:49, Diana Picus via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> Is there any particular reason why we don't have a G_CALL and G_RET
> operator? I think it would be nicer to generate a G_CALL here and let
> the instruction selector decide which particular incantation to use.
> What do you guys think?

I can think of a couple of justifications for the current system,
though I didn't actually consider it at the time and I'm very open to
changing if we think it's better.

The biggest barrier to a G_CALL instruction is probably the type
system: double and i64 behave very differently in calls, but both get
lowered to s64 in generic MIR. There's also the various attributes
that can be attached to a call which affect the ABI (byval, sret,
swift_wtf, ...).

Other than that, formal arguments are a bit of sticky area. You can't
ignore them because each vreg needs a definition, but if you're
lowering those at translation-time, why not do the strongly-related
parts?

You'd probably have to add a G_FORMAL_ARGS instruction or something.
But that has its own issues. It *really* needs to be glued to the top
of the function in a way no other instruction does because it uses
live-in physregs to the entry block. I don't think there's a way to
represent that at the moment (hasSideEffects, mayLoad, mayStore
probably do it in practice).

> On AArch64 we get the calling convention from the MIRBuilder, but IIUC
> that's the calling convention of the caller, which may be different
> from that of the call. Is that a bug?

Yep. I think I was vaguely aware of that at one point but for some
reason fixing it slipped my mind.

Cheers.

Tim.


More information about the llvm-commits mailing list