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

[Diana Picus via llvm-commits]

Hi Tim,

Thanks for the detailed answer.

On 21 February 2017 at 16:40, Tim Northover <t.p.northover at gmail.com> wrote:
> 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, ...).

Hm, I guess I wasn't really going that far, I was mostly thinking of
G_CALL as a placeholder for BLX / BL / BMOVPCRX_CALL / whatever, with
just one operand (the callee). Everything else would still go in regs
/ on the stack, where the ABI wants them, but we'd have a single way
to refer to calls up until the instruction selector. That should make
it easier for other passes to fiddle with them if needed. For
instance, we now have code that changes direct calls with more than 2
users into indirect calls as part of ARMTargetLowering::LowerCall - if
we wanted to move that out of lowering and into a separate pass (not
that it's a major concern), it would be easier to match calls if they
were just G_CALL.

> 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.

Ok, I'm not sure we can get it from the current args, we might have to
pass it in separately.

Oh, and I just remembered another thing that I wanted to ask - with
SelectionDAG we always mark unused registers as dead (in
InstrEmitter::EmitMachineNode). Shouldn't we do that with GlobalISel
too?

Thanks,
Diana