3 ms·

> I do think the blog post implies that v8 can't do polymorphic inlining. It took me a bit to realize where this confusion comes from (especially given the wh

by mraleph 12y ago

> I do think the blog post implies that v8 can't do polymorphic inlining. It took me a bit to realize where this confusion comes from (especially given the whole discussion of how polymorphic property access is handled). Is it due to "Undiscussed - Not all caches are the same" section? Indeed V8 can't at the moment do polymorphic inlining at non-method callsites - f(), however it can on method callsites o.m(). The reason for this is lack of type feedback. I will seek to clarify the wording in that section. > Aside: That was a very thorough and well written blog post, mraleph :) A very enjoyable read. Thanks.

kannanvijayan 12y ago
Well, if you extend the call ICs to record multiple callees at the site, I'm assuming it would be pretty straightforward to do this for all calls. Not sure if it's worth the effort, though. I think most of the reason SM has polymorphic inlining for all callsites is that we added it first as a stop-gap for methodcall inlining, and then later went back and added support for method callsites (guarding directly on the receiver object's type and eliding the property lookup - which I assume is what V8 did from the start). If you already have methodcall polymorphic inlining, the return on investment in expanding that to all callsites is perhaps pretty low. Would be interesting to measure though..
- mraleph 12y ago
  I have amended the section, please check it out. There is certain technical heritage here. Originally method calls compiled down to a single IC that did load and call within a IC stub. Type feedback from these ICs was interpreted in the same way as from property load ICs. On the other hand function calls cb(...) compiled down to a call through CallFunctionStub which did not record any feedback whatsoever. At some point CallFunctionStub learned to record a bit of type feedback (monomorphic / megamorphic) and we started using it in Crankshaft for speculative inlining. Only recently method calls were decomposed into Load IC and a separate Call IC (an evolved CallFunctionStub) which invokes loaded function. For property invocation o.m(...) feedback comes from the Load IC now, and Call IC feedback is ignored. For variable invocation cb(...) feedback comes from the Call IC - which is still only able to distinguish only monomorphic and megamorphic state.
  - kannanvijayan 12y ago
    Ah, makes sense. I just read through the updated post (took me a bit to find the updated text), and it does clear up the methodcall polymorphism bit.

by mraleph 12y ago

kannanvijayan 12y ago

Well, if you extend the call ICs to record multiple callees at the site, I'm assuming it would be pretty straightforward to do this for all calls. Not sure if it's worth the effort, though. I think most of the reason SM has polymorphic inlining for all callsites is that we added it first as a stop-gap for methodcall inlining, and then later went back and added support for method callsites (guarding directly on the receiver object's type and eliding the property lookup - which I assume is what V8 did from the start). If you already have methodcall polymorphic inlining, the return on investment in expanding that to all callsites is perhaps pretty low. Would be interesting to measure though..

mraleph 12y ago
I have amended the section, please check it out. There is certain technical heritage here. Originally method calls compiled down to a single IC that did load and call within a IC stub. Type feedback from these ICs was interpreted in the same way as from property load ICs. On the other hand function calls cb(...) compiled down to a call through CallFunctionStub which did not record any feedback whatsoever. At some point CallFunctionStub learned to record a bit of type feedback (monomorphic / megamorphic) and we started using it in Crankshaft for speculative inlining. Only recently method calls were decomposed into Load IC and a separate Call IC (an evolved CallFunctionStub) which invokes loaded function. For property invocation o.m(...) feedback comes from the Load IC now, and Call IC feedback is ignored. For variable invocation cb(...) feedback comes from the Call IC - which is still only able to distinguish only monomorphic and megamorphic state.
- kannanvijayan 12y ago
  Ah, makes sense. I just read through the updated post (took me a bit to find the updated text), and it does clear up the methodcall polymorphism bit.