[llvm-dev] Setting llvm::TargetOptions::GuaranteedTailCallOpt in LTO Code Generation

[Eli Friedman via llvm-dev]

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Dwight Guth via llvm-dev
Sent: Wednesday, September 18, 2019 1:02 PM
To: Steven Wu <stevenwu at apple.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] Setting llvm::TargetOptions::GuaranteedTailCallOpt in LTO Code Generation

On Wed, Sep 18, 2019, 2:39 PM Steven Wu <stevenwu at apple.com<mailto:stevenwu at apple.com>> wrote:



On Sep 18, 2019, at 10:24 AM, Steven Wu <stevenwu at apple.com<mailto:stevenwu at apple.com>> wrote:

I also feel like passing -tailcallopt in the linker stage is kind of fragile. It is better to create an attribute (on function or callInst) to force tailcallopt and some compiler flag to generated that during IRGen.

I think I missed you comments about `musttail`. Do you have any example to show why `musttail` doesn’t work for you? Is there anything we can do to make it work so we don’t need to rely on `-mllvm` options?

Steven

The problem with musttail is that the behavior of the feature is that IR does not verify if it includes a musttail call where the caller and callee have different numbers of arguments or otherwise differ in certain respects. However, we need guaranteed tail calls for mutually recursive functions, which obviously may not have the same signature. I would love to be able to use musttail though. Maybe you could make musttail functions with a compatible calling convention use the same codepath as -tailcallopt, and then loosen the restrictions? I'm not really sure. I can foresee there might be problems with calling convention if the function was externally visible, but for our use case it should be fine if the looser musttail attribute only worked for functions local to a module, I think...

We could extend the circumstances under which we allow musttail, sure.  But we could only allow arbitrary mismatched argument lists with specific calling conventions where we know it’s actually possible to lower them.  And currently, there is no such convention. (Well, technically there’s x86_stdcall, but that only works on 32-bit x86.  And the GHC and HiPE calling conventions are weird in other ways.)

We could add a new calling convention that’s equivalent to “fastcc with GuaranteedTailCallOpt”, though, and give it special musttail rules.  Maybe call it “tailcc”.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190918/085b079e/attachment.html>