[llvm-dev] [GlobalISel][MIPS] Legality and instruction combining
pavram via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 14 06:50:24 PDT 2018
Hi Daniel,
On 13.09.2018. 19:32, Daniel Sanders wrote:
> Could you clarify what you mean here? The new legalizer info can
> define this with:
> getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32)
> so I'm guessing you mean that code to mutate the G_SELECT is currently
> missing
Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't do
that for TypeIdx==1. Is it intentionally implemented this way?
>> b) Is the plan to sometimes let s1 as legal type and ignore it later?
> I'm not sure what you mean here
>
For example lets look at AArch64 G_SELECT:
getActionDefinitionsBuilder(G_SELECT)
.legalFor({{s32, s1}, {s64, s1}, {p0, s1}})
.clampScalar(0, s32, s64)
.widenScalarToNextPow2(0);
In this case LLT of operand 1 (s1) in G_SELECT has size 1, and
corresponding register class in selected instruction has size 32 (that
is $src1 in AArch64::ANDSWri, it has GPR32 regsiter class).
For that reason s1 is practically ignored and silently converted to s32.
We could get similar result if we have:
getActionDefinitionsBuilder(G_SELECT)
.legalFor({{s32, s32}, {s64, s32}, {p0, s32}})
.clampScalar(0, s32, s64)
.clampScalar(1, s32, s32)
.widenScalarToNextPow2(0);
And in this case sizes of LLTs and register classes would be the same.
Implementation for G_ICMP on AArch64 is very similar to second described
option for G_SELECT.
Is there a reason for different implementation of G_SELECT and G_ICMP on
AArch64? Are there some general ruses to determine which of the two
given options is better in which case?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180914/3bf07fce/attachment.html>
More information about the llvm-dev
mailing list