<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 2015-09-30 01:15, Matthias Braun
      wrote:<br>
    </div>
    <blockquote
      cite="mid:0229079F-F24C-42DA-B4C6-0324DE00348D@apple.com"
      type="cite">
      <pre wrap="">A similar setting occurs with ARM Thumb code which for many instructions has a short 2-address encoding and a longer 3 address form. As far as I know this is done by selecting the 3 address form and rewriting them to 2-address after register allocation where possible. See lib/Target/ARM/Thumb2SizeReduction.cpp.

- Matthias
</pre>
    </blockquote>
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    <p style="margin-bottom: 0in; line-height: 100%">The late
      oportunistic conversion is simple, but can only work in cases
      where
      regalloc happens to put the new definition in the same register as
      one of the source operands. In case regalloc would try to do this
      as
      much as possible, this might work most of the time, however I have
      no idea if this is
      the case. Some targets may want round-robin allocation, while
      others
      would prefer reuse of registers. Steve says he gets most of it
      handled, how about ARM Thumb? Is this with RAGreedy?<br>
    </p>
    <title></title>
    <meta name="generator" content="LibreOffice 4.2.8.2 (Linux)">
    <style type="text/css">
        <!--
                @page { margin: 0.79in }
                p { margin-bottom: 0.1in; line-height: 120% }
        -->
        </style>
    <blockquote
      cite="mid:0229079F-F24C-42DA-B4C6-0324DE00348D@apple.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">On Sep 29, 2015, at 2:22 PM, Quentin Colombet via llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> wrote:

Hi Jonas,

</pre>
        <blockquote type="cite">
          <pre wrap="">On Sep 29, 2015, at 2:00 AM, Jonas Paulsson via llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> wrote:

Hi,

I have cases of instruction pairs, where one is cheaper 2-address, and the other 3-address. I would like to select the 2-addr instruction during isel, but use the 3-addr instruction to avoid a copy if possible. I find that TwoAddressInstructionPass::isProfitableToConv3Addr() is only checking
for the case of a physreg copy, and so leaves the majority of cases as they are (2-address).

I would like to say "If 3-addr version would avoid a copy, use it!". Does anyone else have a similar situation?
</pre>
        </blockquote>
        <pre wrap="">
I think this is what it is supposed to do right now :). Though I reckon the test is probably over conservative in the sense that it returns true only if it can prove this is going to save a copy.</pre>
      </blockquote>
    </blockquote>
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    <p style="margin-bottom: 0in; line-height: 100%">Yes, it is very
      much
      overconservative because it only checks the cases of phys-reg
      copies
      around calls and returns, meaning that all other cases are never
      transformed. I believe it should ask target to convert to
      3-address
      in all cases no source register is killed.<br>
    </p>
    <p style="margin-bottom: 0in; line-height: 100%">
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
    </p>
    <p style="margin-bottom: 0in; line-height: 100%">
      <title></title>
      <meta name="generator" content="LibreOffice 4.2.8.2 (Linux)">
      <style type="text/css">
        <!--
                @page { margin: 0.79in }
                p { margin-bottom: 0.1in; line-height: 120% }
        -->
        </style>
      <p style="margin-bottom: 0in; line-height: 100%">PPCVSXFMAMutate
        is
        indeed doing something towards the same goal. I wonder if this
        pass
        could be removed/simplified if TwoAddress would be aware of kill
        flags and eliminate more copys?</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
    </p>
    <title></title>
    <meta name="generator" content="LibreOffice 4.2.8.2 (Linux)">
    <style type="text/css">
        <!--
                @page { margin: 0.79in }
                p { margin-bottom: 0.1in; line-height: 120% }
        -->
        </style>
    <blockquote
      cite="mid:0229079F-F24C-42DA-B4C6-0324DE00348D@apple.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">

</pre>
        <blockquote type="cite">
          <pre wrap="">
To do this, one would need to check the kill-flag on the tied use operand. If it is not killed, one can assume that the use and dst registers overlap, and therefore the copy is needed for the two-address form. The kill flags would however need to be recomputed by TwoAddr pass, since
LiveVariables clear them.

An alternative approach might be to have something like TII->handleMachineFunctionPostCoalescer() at the end of RegisterCoalescer.cpp::runOnMachineFunction(). There, one could look for instructions and query live intervals for overlap. This hook might also be useful for other things, since this is the point just before mi-sched/regalloc, where one could do things like estimate register pressure.

Any comments on this anyone?
</pre>
        </blockquote>
        <pre wrap="">
We could try to fix the check in two-address pass first. I believe a hook like you describe might be useful but this is yet another thing to teach the coalescer, which is already complex enough IMO. Moreover, I like the separation of concerns that 2- and 3-addr conversions are made within a dedicated pass.
That being said, if getting the best code involves teaching the coalescer about this transformation, sure!

Cheers,
Q.

</pre>
      </blockquote>
    </blockquote>
    <blockquote
      cite="mid:0229079F-F24C-42DA-B4C6-0324DE00348D@apple.com"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">
/Jonas Paulsson

_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
    / Jonas<br>
    <br>
  </body>
</html>