On 2009.01.12., at 2:14, Cameron McCormack wrote:
Norris Boyd wrote:
I think the real bug here is a missing call to convertParameter() for
the index expression in the Token.SETELEM case. This call will
convert
the parameter to an object type. I've checked in a fix and updated
the
bug. This fix is suboptimal in that if a number is passed in as a
parameter, then the number will be converted to an object rather than
using that number value in a call to the special
OptRuntime.setObjectIndex. But for the non-parameter case
OptRuntime.setObjectIndex should still be used if the index is a
number.
Understood. I didn't realise that that was the purpose of
convertParameter(). (The method name isn't that intuitive, and the
method isn't documented.) But also I guessed that there should be a
way
of telling if a function parameter is always called with a number, but
maybe the data flow analysis doesn't determine that?
To me (as far as solving the problem of emitting efficient code for
special cases is concerned) the TraceMonkey approach is very
appealing; it basically creates separate instances of the code for
various known combinations of types in parameters as it encounters
them in the execution. Obvious drawback being that you can end up with
quite a lot of specialized generated code instances...
Attila.
--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
