[PATCH] D155638: [llvm-reduce] Reduce function calling convention
Matt Arsenault via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 18 15:11:47 PDT 2023
arsenm added inline comments.
================
Comment at: llvm/tools/llvm-reduce/deltas/ReduceFunctionBodies.cpp:46
+ case CallingConv::C:
+ case CallingConv::AMDGPU_CS_Chain:
+ return false;
----------------
aeubanks wrote:
> arsenm wrote:
> > aeubanks wrote:
> > > aeubanks wrote:
> > > > I think this should be a list of CCs to opt-out, rather than opt-in to calling convention reduction since it really should be fine to reduce them to CCC in terms of legality.
> > > >
> > > > For the amdgpu entry-point concerns, that's the point of the interestingness test?
> > > oh I forgot to ask the initial question, if you do want to opt out some CCs, which ones do you want to opt out?
> > I think opt-in is basically always a better system, especially for target stuff (which is what any unlisted CC is going to be)
> llvm-reduce is designed to reduce IR as much as possible and I don't think this is an exception, like I said the interestingness test should take care of if you really don't want the CC reduced
You're asserting that cc is reduced or simpler and other calling conventions are not, and I do not think you can view them this way. From an IR perspective it's not really conceptually simpler, it just removes one token from the printed IR. With the possible exception of fastcc, it's not really an optimizing modifier
What it does do is change codegen in arbitrary ways, and I don't think that provides any reduction value on the IR side.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D155638/new/
https://reviews.llvm.org/D155638
More information about the llvm-commits
mailing list