http://codereview.chromium.org/6688062/diff/1/test/mjsunit/mjsunit.js File test/mjsunit/mjsunit.js (right):
http://codereview.chromium.org/6688062/diff/1/test/mjsunit/mjsunit.js#newcode82 test/mjsunit/mjsunit.js:82: var start; On 2011/03/21 13:17:58, Lasse Reichstein wrote:
And it doesn't have to be. I added the second case for message for cases where the type of actual
differs
from expected, but with MjsUnitToString, it doesn't matter as much,
since it
prints strings with quotes around (so we don't get two different
values that
turns to the same string when showing).
I'll try to make it simpler.
Here's where we need printf :) http://codereview.chromium.org/6688062/diff/1/test/mjsunit/mul-exhaustive.js File test/mjsunit/mul-exhaustive.js (right): http://codereview.chromium.org/6688062/diff/1/test/mjsunit/mul-exhaustive.js#newcode55 test/mjsunit/mul-exhaustive.js:55: for (var i = 0; i < 1000; i++) assertEquals(a, xcyv(y)); On 2011/03/21 13:17:58, Lasse Reichstein wrote:
If anything, I should check which constant is necessary to make it
optimize with
--opt-eagerly. The problem is that this test runs rather long, so if I increase it to
10000, it
does optimize more anonymous functions (using --always-opt and
--opt-eagerly),
but not all of them anyway. If I go to 100000, it starts to take
several
minutes. I'll use 10000 for now, but suggestions are welcome.
I think I'd just leave it out of this test. We *do* need better tests of the optimizing compiler, but this way is so indirect and not guaranteed to always test what we want it to test. We should try to come up with a way to write unit tests for the individual instructions instead. http://codereview.chromium.org/6688062/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
