Closed Bug 648502 Opened 13 years ago Closed 13 years ago

TI+JM: incorrect result with stricteq, inlining

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jandem, Unassigned)

References

Details

Attachments

(1 file)

153 bytes, application/x-javascript
Details
Attached file Testcase
$ ./js -a -n -m test.js
true
true
true
false <- should be true

Revision a9f916668b29, but I can also reproduce with a build from yesterday. Probably a regression from inlining scripted calls.
Good test case! (real design problem)

During compilation, we coerce things marked by inference as int|float as definitely float, to avoid type tag tests etc.  Which values are coerced to int|float is not stable across compilations due to changing type information, though as compilations progress a value can only go from int -> float and not vice versa.  When recompiling we check that any frames on stack have types consistent with the new compilation, coercing ints to floats where necessary.

The problem is that when expanding inline frames we do a similar thing, creating a stack frame from the inlined version, and the compilation which inlined the frame may have a different type from the compilation of the inlined function (i.e. we know that in the last call to 'f' the second arg is an int, but 'f' is also called with floats and thus treats its arg as a float), and we don't do a similar coercion.

We really can't do such a coercion while expanding, because when expanding we already have the compiled version of the inlined function, and after compilation we forget what things the compiler thinks are doubles at each PC (it might have better information than inference in some cases, e.g. 'x = 2; ... x ...' when x is assigned a float elsewhere).

So we need to bake information into the JITScript about what things are thought to be doubles at each rejoin point, and the simple/easy place to do that is in the code generated at the rejoin points.  Thought about that as the original design for this, but if the coercion code is executed many times (e.g. after every scripted call) it will slow things down.  An alternative, which is as fast, simpler, and correct(er) than what we have now is to not allow rejoining at normal calls, but only special rejoin calls which are emitted on the OOL path but don't have incoming jumps and perform all necessary coercions.

Folding this into bug 647991, which will be making related changes.
Depends on: 647991
Fixed as part of bug 647991.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: