The problem is that given code like this:

  a = b + c
  d = a + e
  ...
  ... (use of a) ...

Lowering may produce code like this, at least on x86:

  T1 = b
  T1 += c
  a = T1
  T2 = a
  T2 += e
  d = T2
  ...
  ... (use of a) ...

If "a" has a long live range, it may not get a register, resulting in clumsy code in the middle of the sequence like "a=reg; reg=a".  Normally one might expect store forwarding to make the clumsy code fast, but it does presumably add an extra instruction-retirement cycle to the critical path in a pointer-chasing loop, and makes a big difference on some benchmarks.

The simple fix here is, at the end of lowering "a=b+c", keep track of the final "a=T1" assignment.  Then, when lowering "d=a+e" and we look up "a", we can substitute "T1".  This slightly increases the live range of T1, but it does a great job of avoiding the redundant reload of the register from the stack location.

A more general fix (in the future) might be to do live range splitting and let the register allocator handle it.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=4095
R=kschimpf@google.com

Review URL: https://codereview.chromium.org/1385433002 .