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

[Eli Friedman via llvm-dev]

From: Dwight Guth <dwight.guth at runtimeverification.com>
Sent: Wednesday, September 18, 2019 2:03 PM
To: Eli Friedman <efriedma at quicinc.com>
Cc: Steven Wu <stevenwu at apple.com>; 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 at 3:32 PM Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>> wrote:
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

What you suggest (a new tail-callable calling convention equivalent to fastcc with GuaranteedTailCallOpt) sounds like a solution that would work for us. But it also sounds like something significant enough in scope that it might be difficult for me to complete myself, when I am barely familiar with the codebase. I feel confident I could probably add a new function attribute that is equivalent to specifying GuaranteedTailCallOpt=true if it is present on both the callee and caller functions, but I doubt I have the skills necessary to create an entirely new calling convention AND modify the musttail semantics to have knowledge of it. Is this something someone would actually be willing to work on or at the very least help me figure out? Or is the former solution also considered viable?

Adding a function attribute that changes the meaning of fastcc would produce a consistent result, but it’s less than ideal in other respects. It works badly if you try to mix functions with different target attributes.  (See https://reviews.llvm.org/D53554 for the sort of issue I’m talking about.)  You lose access to the normal fastcc, which is generally faster for non-tail calls.  And it becomes impractical to relax musttail checking the way I proposed, so you’re depending on a best-effort lowering; certain transforms will clear the “tail” flag, like ArgumentPromotion.
Adding a new calling convention isn’t really as hard as it sounds; it’ll mostly be reusing existing code.  Try to grep for, for example, X86_ThisCall.  You basically only need to modify IR serialization and deserialization, and a few places in target-specific code for each target that supports the convention.
-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190919/338b3280/attachment.html>