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

[Leslie Zhai via llvm-dev]

Hi Alex,

Please review my patch D41700 again, thanks a lot!

Thanks for LLVM developers' code view, I can rebase my patch based on 
D40805 .

1. Consider about `IsFixed` and `OrigTy`, but assert as firstly:

assert(IsFixed && "IsFixed support not yet implemented");
assert(OrigTy && "OrigTy support not yet implemented");

The implementation of `RISCVCCState` will be in the next patch, please 
give me some suggestion about custom `RISCVCCState` inherited from 
`CCState`, I think, at least, it needs to cover `IsFixed` and `OrigTy`.

2. Remove parameter `DL` for `CC_RISCV`, because it is able to use:

State.getMachineFunction().getDataLayout();

through parameter `State`.


在 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 - https://reviews.llvm.org/p/xiangzhai/