Edit (yet again): My initial conclusions were wrong, and it's nearly certainly cheating. Dammit. I hate being wrong in front of people smarter than me. :<

----

I'm running the same benchmark independently right now. Core i7 in a Win7 64-bit install.

For each test, I did 5 runs and averaged them. I increased the number of loops in each test from 25,000 to 250,000 as well.

Chrome 9.0.576.0
Stock: 105.28ms
With "true": 104.44ms

MS IE 9.0.7930.16406
Stock: 10.98ms
With "true": 181.16ms

That's a pretty interesting jump.

Here's a fun little observation:

Chome: 8.6ms
IE: 10.9ms

--- tests/sunspider-0.9.1/math-cordic.js 2010-11-17 00:55:29.000000000 -0700
+++ tests/sunspider-0.9.1-deadcode/math-cordic.js 2010-11-17 01:10:36.000000000 -0700
@@ -63,6 +63,7 @@
TargetAngle = FIXED(28.027);
CurrAngle = 0;
for (Step = 0; Step < 12; Step++) {
+ return;
var NewX;
if (TargetAngle > CurrAngle) {
NewX = X - (Y >> Step);

By returning immediately out of the loop, Chrome's time drops by a factor of 12.1, whereas IE's stays pretty much constant.

I suspect what's happening here is that the IE engine is somehow marking that entire function as deadcode, and thus, not running it; the ~10ms accounts for the time it takes to run that for loop 250k times, but the cordicsincos() code is not being run at all. Ironically, deadcode somewhere in the function causes the engine to NOT throw it all away, and its gets run.

In fact, if we just kill that for loop all together:

--- tests/sunspider-0.9.1/math-cordic.js 2010-11-17 00:55:29.000000000 -0700
+++ tests/sunspider-0.9.1-deadcode/math-cordic.js 2010-11-17 01:16:36.000000000 -0700
@@ -62,20 +62,6 @@

TargetAngle = FIXED(28.027);
CurrAngle = 0;
- for (Step = 0; Step < 12; Step++) {
- *snip for brevity*
- }
}

We get the following times:

Chrome: 8.9ms
IE: 10.6ms

What I suspect is that the IE engine is seeing "Okay, nothing is returned, and nothing outside of the scope of this function is ever altered", so once it steps into it, it just immediately returns. This is arguably correct behavior! That code is, for all practical purposes, worthless.

If we just move one of the variable references out of function scope (or just remove the var, making it effectively a global variable), IE takes the extra time to run:

--- tests/sunspider-0.9.1/math-cordic.js 2010-11-17 00:55:29.000000000 -0700
+++ tests/sunspider-0.9.1-deadcode/math-cordic.js 2010-11-17 01:22:49.000000000 -0700
@@ -50,11 +50,11 @@

+var CurrAngle;
function cordicsincos() {
var X;
var Y;
var TargetAngle;
- var CurrAngle;
var Step;

X = FIXED(AG_CONST); /* AG_CONST * cos(0) */

Chrome: 99.9ms
IE: 217.1ms

Sorry, guys. I like a good IE bash-fest (Hey, it's still slower than V8 when it actually runs the code!) as much as anyone, but I think it's legit here. The benchmark is poorly-conceived, and IE does the right thing with it, though it obviously distorts the scores in their favor. That's a problem with the benchmark, though, not IE.

Edit (like...#14): It could well just be cheating on analysis in this particular case, which I stupidly overlooked. For example, this diff:

--- tests/sunspider-0.9.1/math-cordic.js 2010-11-17 00:55:29.000000000 -0700
+++ tests/sunspider-0.9.1-deadcode/math-cordic.js 2010-11-17 02:09:34.000000000 -0700
@@ -62,7 +62,7 @@

TargetAngle = FIXED(28.027);
CurrAngle = 0;
- for (Step = 0; Step < 12; Step++) {
+ for (Step = 12; Step > 0; Step--) {
var NewX;
if (TargetAngle > CurrAngle) {
NewX = X - (Y >> Step);

Results in runtimes of:

Chrome: 246.8ms
IE: 956.5ms

Replacing the for with a while also results in long runtimes:

--- tests/sunspider-0.9.1/math-cordic.js 2010-11-17 00:55:29.000000000 -0700
+++ tests/sunspider-0.9.1-deadcode/math-cordic.js 2010-11-17 02:12:03.000000000 -0700
@@ -59,10 +59,11 @@

X = FIXED(AG_CONST); /* AG_CONST * cos(0) */
Y = 0; /* AG_CONST * sin(0) */
+ Step = 0;

TargetAngle = FIXED(28.027);
CurrAngle = 0;
- for (Step = 0; Step < 12; Step++) {
+ while(Step < 12) {
var NewX;
if (TargetAngle > CurrAngle) {
NewX = X - (Y >> Step);
@@ -75,6 +76,7 @@
X = NewX;
CurrAngle -= Angles[Step];
}
+ Step++;
}
}

Chrome: 103.4ms
IE: 190.0ms

So, my initial conclusions were wrong. Its dead code analysis is either incredibly narrow, or it was hand-crafted to optimize out that part of the benchmark. Either way it's rubbish.