[PATCH] D143498: Reapply "[AMDGPU] Modify adjustInliningThreshold to also consider the cost of passing function arguments through the stack"

Janek van Oirschot via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 8 05:45:28 PST 2023


JanekvO added inline comments.


================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp:1178
 
+  // In case of indirect calls, callee Function may not be retrievable from the
+  // CallBase.
----------------
scchan wrote:
> JanekvO wrote:
> > arsenm wrote:
> > > JanekvO wrote:
> > > > arsenm wrote:
> > > > > This also will fail for constexpr casts and aliases. You don’t need to give up on these cases. You should be going off the callee type you can get from the CallBase 
> > > > I couldn't get `isArgPassedInSGPR` working with only the `CallBase`. Do indirect calls always pass args through VGPR?
> > > The calling convention is always the same and can’t be different for direct or indirect calls. The ABI is fully determined by the call type, the calling convention and the attribute set. Is there just a missing attribute wrapper for inreg that checks callee and callsite attributes?
> > Ah, I thought `isArgPassedInSGPR` depended more on information on the `Argument` and its associated called `Function`. Seem it only really needs the inreg/byval attribute info of the arguments.
> If it's an indirect call, where's no inlining opportunity or am I missing something?
It can possibly still inline in specific cases (such as the one in the provided test). Moreover, the `llvm::getInlineCost (CallBase &Call, Function *Callee, ...` API that eventually calls this TTI hook may have calls (e.g., from LTO) where the `CallBase &Call` is for an indirect call without a known Called function but the user of the API provides a known `Function *Callee` (i.e., `Call.getCalledFunction() != Callee`).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143498/new/

https://reviews.llvm.org/D143498



More information about the llvm-commits mailing list