search for: assignarg

...'t actually full so maybe we should move OutputArg::IsFixed into ArgFlagsTy now. AArch64, Hexagon, RISCV, and SystemZ all have the same requirement. AArch64 works around it by calling its CCAssignFnForCall helper for every argument (and passing IsFixed through to that). For GISel, it overrides assignArg so a different function can be called for varargs. I'd be in favour of adding IsFixed to ArgFlagsTy even if it did "overflow" ArgFlagsTy. I know there's an argument about "death by a thousand papercuts", but is the size of ArgFlagsTy really critical anyway? > I thin...

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

...aybe we should move OutputArg::IsFixed into ArgFlagsTy now. > > AArch64, Hexagon, RISCV, and SystemZ all have the same requirement. > AArch64 works around it by calling its CCAssignFnForCall helper for > every argument (and passing IsFixed through to that). For GISel, it > overrides assignArg so a different function can be called for varargs. > > I'd be in favour of adding IsFixed to ArgFlagsTy even if it did > "overflow" ArgFlagsTy. I know there's an argument about "death by a > thousand papercuts", but is the size of ArgFlagsTy really critical...

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

...ectly 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 C...

...; 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) T...

Hi, I would like to start a new porting of GlobalIsel for RISCV. An initial patch about GlobalIsel infrastructure for RISCV was ready now: https://reviews.llvm.org/D65219 There is another porting patch https://reviews.llvm.org/D41653 posted by Leslie Zhai at the end of 2017. I have checked with Leslie about the status of this patch.He has stopped developing it since some questions need be