<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 29, 2013 at 5:53 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>To confirm Owen's analysis I can tell you that bzip2 on x86 appears highly sensitive to register allocation with a jitter of ~3%. (Although it seems to contradict Agner's statements that SandyBridge renames partial registers).</div>
</blockquote><div><br></div><div>The more measurements I do, the more I come to believe that at least on SandyBridge what is happening is this:</div><div><br></div><div>movb (...,%rax), %al</div><div><br></div><div>We have a partial write and a full read of %rax. Even though this is reading a clobber of %rax, this still ends up paying *some* of the cost of the partial register write, but not all of it. My guess is that this is the opcode for the merge rather than a stall due to a dependency, but I'm just guessing at that point. What seems consistent is that if the destination register of the movb has no full 64bit (or 32bit) reads, we don't pay the cost. But again, I say "seems" consistent, but its hard to tell because testing it involves manually re-allocating registers to achieve that prediction, and that can cause jitter as you say. =/ Performance testing is hard.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> Either way it would be great to finally fix this.</div><div><br></div><div>Regarding partial dependece fixing passes, Jakob recently added an optimization to avoid partial flag setting instructions in the thumb2 size reduction pass (there may be other, older attempts that I don’t remember—maybe handling S regs?). Being target specific, the partial CPSR fix just hard codes a couple of high latency opcodes. It should be easy to use the generic TargetSchedModel API instead.</div>
<div><br></div><div>MachineTraceMetrics goes beyond latency and gives you critical path/slack metrics. It can be useful when the tradeoffs are complicated. It might be overkill for a simple heuristic.</div></blockquote></div>
<div class="gmail_extra"><br></div>If there is anything to do here, I think this would both be overkill and wouldn't work. Most of these techniques would conclude that nothing needs to be done here because we write 8bits and then read 8bits, never reading the merged register. The weird thing is that the chip doesn't seem to catch this.<br>
<br></div></div>