search for: calllow

...mail/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 to support calllowering. I h...

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

...ase class yet. Instead, the (one) existing GlobalISel hook currently lives in TargetLoweringBase. For lowering the target specific constraints, we'll have to add a new API that creates (G)MIR during IR translation. Personally I would prefer to have an InlineAsmLowering class, similar to the CallLowering class, which implements the generic algorithm and from which targets can inherit. Most of the implementation in [0] could then be moved to that class. However, this would add yet another class that needs to be wired up in the subtarget class. Is this something we would like to avoid? Is the...

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

...r 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 s...

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

...ly 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 t...

...t; >> 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 o...

As part of our OpenVMS-specific changes, we're adding an arg-count to all of our calls. We've done this as part of callLowering to put the # of slots used into %ah and leaving %al to hold the standard info about vector registers.  That part is working. However, we're struggling somewhat on the code in the prologue to capture the %ah value to then be obtained by our "arg_count" compiler builtin.  We found...