search for: mipsccstate

...te &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...

On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >> a SpeciallCallingConv field. Provides its own implementation of &gt...

I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 c...

...y 2018 at 17:10, Daniel Sanders via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > > Thanks for the insight Daniel, much appreciated. > >>> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >>> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >>> a SpeciallCallingConv field. Provides it...

..., 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...

...on 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 vector...

...it: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html http://lists.llvm.org/pipermail/llvm-dev/2018-August/125094.html Till now, I think we have a reasonable solution to continue the work, the implementation of GlobalIsel from Mips is a good example, which use target-specific "MipsCCState" and "MipsCallLowering::MipsHandler" to handle Call/Arguments/Return lowering. For RISCV, there's no "CCAssignFnForCall" or "CCAssignFnForReturn" functions defined, just like the solution in Mips, a new target-specific "ValueHandler" will be created...