827108 - Make distinction between double's where NaN are observed and not

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Hannes Verschore [:h4writer]]

Just for reference atm. Currently I think the impact isn't big enough for the added complexity.

If we would be able to determine a double can't be a NaN it could simplify some codegeneration a bit and improve speed.

The case I'm looking at is: raytrace.js:223

    initialize : function(x, y, z) {
        this.x = (x ? x : 0);
        this.y = (y ? y : 0);
        this.z = (z ? z : 0);
    },

We can determine that x, y and z are never undefined in the benchmark. Actually the type is always double in this benchmark, but we can specialize the code to:

    initialize : function(x, y, z) {
        this.x = x;
        this.y = y;
        this.z = z;
    },

because NaN also returns false and need a 0. In this testcase NaN never occurs and removing the "if" would give a 1% increase on v8-raytrace.

Another way to solve this, is to decide that when NaN occurs in TestDAndBranch we bailout. Because NaN shouldn't be the main path and it doesn't matter if that path is slow ...

Comment 1

[Mayank Bansal]

Is this still relevant?

Comment 2

[Iain Ireland [:iain]]

This doesn't seem actionable. In general, we don't really have any way to guarantee that a function is never called with NaN arguments. It's also not clear to me how bailing out in TestDAndBranch would help. We have to test for NaN either way. If we never see a NaN, then the two cases are effectively identical. If we ever do see a NaN, then we would rather generate the (quite cheap) code to handle that case, instead of paying the cost of a bailout.