Most CALLPROPs are accessing a property from a singleton object, either a prototype or a global variable (e.g. Math). If inference can identify that a CALLPROP is definitely accessing a particular JSObject, and that JSObject always has a particular JSFunction in one of its properties (either from Foo.prototype.f = function () { ... } in global code or from a builtin like x.charCodeAt), the CALLPROP can be nopped and the pushed value statically resolved to that JSFunction.

(In reply to comment #0) > Most CALLPROPs are accessing a property from a singleton object, either a > prototype or a global variable (e.g. Math). If inference can identify that a > CALLPROP is definitely accessing a particular JSObject, and that JSObject > always has a particular JSFunction in one of its properties (either from > Foo.prototype.f = function () { ... } in global code or from a builtin like > x.charCodeAt), the CALLPROP can be nopped and the pushed value statically > resolved to that JSFunction. Generally, that function object (JSObject), not the underlying compiler-created JSFunction (which is-a JSObject). This is what branding enables with the property cache, TM's shape-guarded hit case, and related JM cases (I forget whether JM brands or just does its own IC thing). /be

Yeah, though branding still requires a shape check on the singleton object so can't be used to totally nop the CALLPROP. With type information and recompilation, we can keep track of the scripts that depend on, e.g. Math.abs to refer to a particular JSObject, and will recompile those scripts should the info change in the future. This should subsume branding, so long as the type information stays precise. Once inference has developed more I hope it will be possible to simplify or remove branding without hurting perf, if doing so will let JSObject shrink more (bug 637931) and reduce the # of dynamic Shape* we make.

We're doing this now.