[llvm-dev] Options for custom CCState, CCAssignFn, and GlobalISel

[Leslie Zhai via llvm-dev]

Hi LLVM developers,

I am not available from February 11th to February 25th due to Chinese 
Spring Festival and my sincere thanks goto:

Anna Zaks:

     She lead me to the LLVM family and reviewed my patch for clang 
analyzer MallocChecker carefully and patiently. Дуже дякую

Artem Dergachev:

     He reviewed my patches for clang analyzer some Checkers carefully. 
Большое спасибо

Dylan McKay:

     He reviewed my patches for AVR Target. Thanks a lot!

Rui Ueyama:

     He taught me how to migrate AVR for LLD. どうもありがとう

Duncan Sands:

     He lead me to the GCC family via migrate DragonEgg to GCC 8.x and 
LLVM 7.x. Merci beaucoup

Alex Bradbury:

     He is my mentor, he is leading me to contribute to RISCV Target. 
Thanks a lot!

Heiher:

     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. 
非常感谢！龙芯战士们临近春节还奋战在Mozilla、Linux 
Kernel、GCC、Binutils，但依然抽出休息时间审核我的工作，非常感激！



在 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 
> D24631.
>
> 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 
>> GlobalISel
>> 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 
>> argument/ret
>> has been split to legal value types. In some cases you want more 
>> information
>> than is available through this function interface, which leads to a 
>> number of
>> backends creating their own CCState subclass:
>>
>> * MipsCCState: adds bool vectors OriginalArgWasF128, 
>> OriginalArgWasFloat,
>> 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 
>> reduces
>> boilerplate vs MipsCCState by just having PPCISelLowering call
>> PPCCCState::PreAnalyzeCallOperands directly.
>> * SystemZCCState: has bool vectors ArgIsFixed and ArgIsShortVector, 
>> works
>> 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 
>> calling
>> convention implementations and to reduce duplicated code as much as 
>> possible.
>> 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 
>> target-specific
>> CCStates.
>> 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 
>> always
>> make do with an EVT instead. [Input welcome!].
>>    * Do any out-of-tree backends have custom calling convention code 
>> that
>> 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 
>> happiest
>> 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?
>>
>> Thanks,
>>
>> Alex
>

-- 
Regards,
Leslie Zhai
GCC developer https://github.com/loongson-community/gcc/
LLVM developer https://reviews.llvm.org/p/xiangzhai/