Displaying 9 results from an estimated 9 matches for "calllowering".
2019 Jul 24
2
About a new porting of GlobalIsel for RISCV
...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 have m...
2018 Jan 03
7
Options for custom CCState, CCAssignFn, and GlobalISel
...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
CCSt...
2020 Apr 06
4
[GlobalISel] Extended inline assembler support
...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 there a...
2018 Jan 13
0
Options for custom CCState, CCAssignFn, and GlobalISel
...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 supp...
2018 Jan 04
2
Options for custom CCState, CCAssignFn, and GlobalISel
...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 subcla...
2018 Jan 05
0
Options for custom CCState, CCAssignFn, and GlobalISel
...;>
>>> 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 CCS...
2018 Jan 04
0
Options for custom CCState, CCAssignFn, and GlobalISel
...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 to sup...
2018 Feb 10
0
Options for custom CCState, CCAssignFn, and GlobalISel
...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 or cus...
2018 Mar 14
2
Capturing x86 %rax in prologue to use in body
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 wher...