[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