<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    Hi Daniel,
    <br>
    <br>
    On 13.09.2018. 19:32, Daniel Sanders wrote:
    <br>
    <blockquote type="cite" style="color: #000000;">Could you clarify
      what you mean here? The new legalizer info can define this with:
      <br>
          getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32)
      <br>
      so I'm guessing you mean that code to mutate the G_SELECT is
      currently missing
      <br>
    </blockquote>
    Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't
    do that for TypeIdx==1. Is it intentionally implemented this way?
    <br>
    <blockquote type="cite" style="color: #000000;">
      <blockquote type="cite" style="color: #000000;">b) Is the plan to
        sometimes let s1 as legal type and ignore it later?
        <br>
      </blockquote>
      I'm not sure what you mean here
      <br>
      <br>
    </blockquote>
    For example lets look at AArch64 G_SELECT:
    <br>
      getActionDefinitionsBuilder(G_SELECT)
    <br>
          .legalFor({{s32, s1}, {s64, s1}, {p0, s1}})
    <br>
          .clampScalar(0, s32, s64)
    <br>
          .widenScalarToNextPow2(0);
    <br>
    <br>
    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).
    <br>
    For that reason s1 is practically ignored and silently converted to
    s32.
    <br>
    We could get similar result if we have:
    <br>
    <br>
      getActionDefinitionsBuilder(G_SELECT)
    <br>
          .legalFor({{s32, s32}, {s64, s32}, {p0, s32}})
    <br>
          .clampScalar(0, s32, s64)
    <br>
          .clampScalar(1, s32, s32)
    <br>
          .widenScalarToNextPow2(0);
    <br>
    <br>
    And in this case sizes of LLTs and register classes would be the
    same.
    <br>
    Implementation for G_ICMP on AArch64 is very similar to second
    described option for G_SELECT.
    <br>
    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?
  </body>
</html>