[llvm-dev] Options for custom CCState, CCAssignFn, and GlobalISel
Leslie Zhai via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 9 17:31:28 PST 2018
Hi LLVM developers,
I am not available from February 11th to February 25th due to Chinese
Spring Festival and my sincere thanks goto:
She lead me to the LLVM family and reviewed my patch for clang
analyzer MallocChecker carefully and patiently. Дуже дякую
He reviewed my patches for clang analyzer some Checkers carefully.
He reviewed my patches for AVR Target. Thanks a lot!
He taught me how to migrate AVR for LLD. どうもありがとう
He lead me to the GCC family via migrate DragonEgg to GCC 8.x and
LLVM 7.x. Merci beaucoup
He is my mentor, he is leading me to contribute to RISCV Target.
Thanks a lot!
He reviewed my backport patches for GCC 5.5, but we are also
tracking the issue for gcc-6/7 branches and gcc-8 trunk.
在 2018年01月13日 18:58, Leslie Zhai 写道:
> Hi LLVM developers,
> Don't be quiet :) we need your suggestions for supporting custom
> CCState, CCAssignFn in D41700.
> And also RegisterBank in D41653. because it needs to consider about
> how to support variable-sized register classes concept implemented in
> And I think you might have same question when porting to GlobalISel
> for your Targets, so please give us some directions, thanks a lot!
> 在 2018年01月04日 06:00, Alex Bradbury 写道:
>> This question came about through reviewing work from Leslie Zhai on
>> support for RISC-V, which also motivated me to revisit code which
>> I've always
>> felt was a bit clunky.
>> Calling convention lowering in LLVM is typically handled by functions
>> conforming to the CCAssignFn typedef:
>> typedef bool CCAssignFn(unsigned ValNo, MVT ValVT,
>> MVT LocVT, CCValAssign::LocInfo LocInfo,
>> ISD::ArgFlagsTy ArgFlags, CCState &State);
>> Notably, these functions are called after type legalisation so an
>> has been split to legal value types. In some cases you want more
>> than is available through this function interface, which leads to a
>> number of
>> backends creating their own CCState subclass:
>> * MipsCCState: adds bool vectors OriginalArgWasF128,
>> OriginalArgWasFloatVector, OriginalRetWasFloatVector,
>> CallOperandIsFixed. Also
>> a SpeciallCallingConv field. Provides its own implementation of
>> AnalyzeFormalArguments etc that fill these vectors.
>> * HexagonCCState: adds a single extra field - NumNamedVarArgParams.
>> * PPCCCState: adds an OriginalArgWasPPCF128 bool vector. Arguably
>> boilerplate vs MipsCCState by just having PPCISelLowering call
>> PPCCCState::PreAnalyzeCallOperands directly.
>> * SystemZCCState: has bool vectors ArgIsFixed and ArgIsShortVector,
>> similarly to MipsCCState or PPCCCState.
>> The above works, but it isn't directly usable in the current GlobalISel
>> implementation. Very sensibly, GISel tries to both reuse existing
>> convention implementations and to reduce duplicated code as much as
>> To this end, CallLowering::handleAssignments will create a CCState
>> and use
>> ValueHandler::assignArg to call a function of type CCAssignFn type.
>> I see a couple of options:
>> 1) Creating a new virtual method in GISel CallLowering that creates and
>> initialises a CCState or custom subclass. Use that to support
>> 2) Try to remove the need for custom CCState altogether. In
>> <https://reviews.llvm.org/D38894>, Shiva Chen adds an OrigVT field to
>> ISD::ArgFlagsTy which seems much cleaner. It's not immediately
>> obvious to me
>> if the in-tree users that currently track Type rather than EVT could
>> make do with an EVT instead. [Input welcome!].
>> * Do any out-of-tree backends have custom calling convention code
>> requires more information than original arg type and whether the
>> argument is
>> fixed or not? In the RISC-V calling convention implementation I'd be
>> if the calling convention function had access to SubtargetInfo and the
>> DataLayout, but can probably do without.
>> Does anyone have views on this, or insight into planned future
>> developments of
>> calling convention handling in GlobalISel?
GCC developer https://github.com/loongson-community/gcc/
LLVM developer https://reviews.llvm.org/p/xiangzhai/
More information about the llvm-dev