This is an archive of the discontinued LLVM Phabricator instance.

SwiftTailCC: teach verifier musttail rules applicable to this CC.
ClosedPublic

Authored by t.p.northover on May 17 2021, 4:39 AM.

Details

Summary

SwiftTailCC has a different set of requirements than the C calling convention for a tail call. The exact argument sequence doesn't have to match, but fewer ABI-affecting attributes are allowed (mostly to be conservative and because we have a reasonable idea of what might actually be useful).

Also make sure the musttail diagnostic triggers if a musttail call isn't actually a tail call.

Diff Detail

Event Timeline

t.p.northover created this revision.May 17 2021, 4:39 AM
t.p.northover requested review of this revision.May 17 2021, 4:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2021, 4:39 AM

Why doesn't the count and sequence of arguments/parameters have to match for swifttail calls?

Why doesn't the count and sequence of arguments/parameters have to match for swifttail calls?

tailcc/swifttailcc use a callee-pop convention, so we can allocate as much stack space as we need for arguments.

We might want to consider relaxing the rules for tailcc as well as swifttailcc, but I guess it doesn't need to happen in this patch.

llvm/docs/LangRef.rst
11347

There's one source of complexity related to allowing undef here you might not have considered: return type promotion (converting a large return value to an indirect argument). In particular, if we need to promote the return type of the musttail call. I think you can make this work, but not sure if targets generate the right sequence.

11350

The way this is organized is hard to read: can you rearrange it to separate the common, non-swittailcc, and the swifttailcc requirements?

t.p.northover marked an inline comment as done.May 20 2021, 2:53 AM

We might want to consider relaxing the rules for tailcc as well as swifttailcc, but I guess it doesn't need to happen in this patch.

I'm happy to do it here, I think it's definitely an improvement worth having.

llvm/docs/LangRef.rst
11347

Return type promotion seems really iffy with tail calls even now. For this module:

declare [16 x i64] @foo()

define [16 x i64] @bar() {
  %res = musttail call [16 x i64] @foo()
  ret [16 x i64] %res
}

AArch64 & ARM don't actually do a tail call but are otherwise correct (no diagnostic because of where the check is; this patch fixes that). X86 does the tail call but tells @foo to use a random bit of @bar's caller's stack for the array.

I don't think the verifier can check that though, it's quite entwined in CodeGen and Verifier.cpp has nothing but a TargetTriple to work with.

Best I can think of is to document that functions with return type promotion probably won't work as expected here.

Added tailcc to the changes, and reworked the documentation to be (hopefully) clearer.

efriedma added inline comments.May 20 2021, 11:02 AM
llvm/docs/LangRef.rst
11347

If the return types match, it's easy to do the "right" thing: we just need to forward the indirect pointer.

It's not high priority to implement, but I'd at least like an appropriate error. And I'm concerned if we don't have any idea how to implement it. I guess one thing we could do is allow passing a null pointer for the promoted return value, and add a null check in the callee before storing the value.

t.p.northover added inline comments.May 21 2021, 4:50 AM
llvm/docs/LangRef.rst
11347

Fair enough, I'll make the X86 backend give an error instead of assuming it knows better than SDAG for now.

Add error message to x86 backend if it can't honour a musttail call. It seems from the (presumably original) musttail.ll test that it's intended to override the disable-tail-calls function attribute, so I had to teach SelectionDAGBuilder about that too.

efriedma added inline comments.May 24 2021, 2:28 PM
llvm/docs/LangRef.rst
11347

I'd also like to see testcases that show we generate the expected "failed to perform tail call elimination" error for the unimplemented cases.

Added test for sret promotion case the verifier can't handle.

This revision is now accepted and ready to land.May 27 2021, 3:20 PM
t.p.northover closed this revision.May 28 2021, 3:12 AM

Thanks Eli, committed as 9ff2eb1ea596.