Tweak the Better{Left,Right}Operand() heuristic

Seems a bit complicated
    1. only double constant is not enough for double instructions to place in right operand. double constant can't be directly inlined in instruction. But if double constant usecount is more than 1, it would be better not to clobber it.
    2. Simply check the (a = a + b) and (a = b + a) inside a loop just as the mentioned benchmark. At each case, we'd better place the "a" operand in the left operand.


General benchmarks(octane,sunspider,kraken) measurement shows that the new heuristic does not have measurable negative impact.

BUG=

[Benedikt Meurer, 2013-09-09 14:39:02]

What is the benefit?

[weiliang.lin2, 2013-09-09 14:49:43]

On 2013/09/09 14:39:02, Benedikt Meurer wrote:
> What is the benefit?

Avoid unnecessary register move. 
For example, it brings more than 40% improve for misc-basic-fpops.js on IA32 in
awfy
http://www.arewefastyet.com/#machine=11&view=breakdown&suite=misc

[Jakob Kummerow, 2013-09-09 19:08:22]

This does not lgtm. It is very unintuitive why Double vs. Int32 representation
would have anything to do with whether operands are better swapped or not.
Probably this benchmark just happens to create a situation where our heuristic
makes the wrong decision. Maybe Better{Left,Right}Operand() should be made
smarter? Changing behavior based on representation does not seem right.

[weiliang.lin2, 2013-09-10 14:50:26]

On 2013/09/09 19:08:22, Jakob wrote:
> This does not lgtm. It is very unintuitive why Double vs. Int32 representation
> would have anything to do with whether operands are better swapped or not.
> Probably this benchmark just happens to create a situation where our heuristic
> makes the wrong decision. Maybe Better{Left,Right}Operand() should be made
> smarter? Changing behavior based on representation does not seem right.

Yes, after revisit the issue, I also find that simply removing this feature for
double value is not correct.
It would be better to make Better{Left,Right}Operand()smarter. And it is also
possible that the benchmark I used seems to be just a corner case which enlarges
the negative impact of xmm register move. WIP....

I paste the benchmark here in case you can't access it. 


function test_add(x, y) {
  var z = 0;
  for (var i = 0; i < x; i++)
    z += y;
}

test_add(0x3ffffff, 10.5);

function test_mul(x, y) {
  var z = 10;
  for (var i = 0; i < x; i++)
    z = z * y;
}

test_mul(0x3ffffff, 10.5);

[weiliang.lin2, 2013-09-11 12:23:24]

A new fix direction based on comments. Please have a review. Thanks

[haitao.feng, 2014-05-15 05:56:20]

https://codereview.chromium.org/23717039/diff/8001/src/hydrogen-instructions.h
File src/hydrogen-instructions.h (left):

https://codereview.chromium.org/23717039/diff/8001/src/hydrogen-instructions....
src/hydrogen-instructions.h:3550: 
How about writing codes in this way?
-    if (left()->IsConstant()) return true;
-    if (right()->IsConstant()) return false;
+    if (left()->IsConstant() && left()->EmitAtUses()) return true;
+    if (right()->IsConstant() && right()->EmitAtUses()) return false;
+
+    // If destination is one operand of the phi node, they might be allocated
+    // to the same register by hinting.
+    if (left()->IsPhi()) {
+      HPhi* phi = HPhi::cast(left());
+      for (int i = 0; i < phi->OperandCount(); i++) {
+        if (phi->OperandAt(i) == this) return false;
+      }
+    } else if (right()->IsPhi()) {
+      HPhi* phi = HPhi::cast(right());
+      for (int i = 0; i < phi->OperandCount(); i++) {
+        if (phi->OperandAt(i) == this) return true;
+      }
+    }