<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 30, 2016 at 3:45 AM, Krzysztof Parzyszek via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem is that at the moment, the last instruction in<br>
  EAX = ...<br>
  AX = ...<br>
  ... = EAX<br>
would seem to only use the value from the second one, since AX= defines all lanes/units that EAX has. This kind of inaccuracy is not just suboptimal, it would lead to an incorrect conclusion. Currently, only x86-specific knowledge would tell us that the first instruction is still live, and I'd like to be able to tell by examining lane masks/reg units.</blockquote><div><br></div><div>Code like this does works ok to merge the top half of EAX with the new value inserted in AX (or AL, AH), but on many CPUs it is very slow -- slower than using proper machine-independent masking operations.</div><div><br></div><div>This is because the CPUs *themselves* track EAX and AX separately in the register renaming machinery, and have to wait until the write to AX has actually retired before EAX can be read again.</div><div><br></div><div>On Pentium Pro, P2, P3 this caused about a half dozen cycle stall. On Core2 it was reduced to 2 or 3 cycles. I'm not sure about P4. I think not good :-) Sometime around Nehalem or Sandy Bridge it was finally eliminated.</div><div><br></div></div></div></div>