You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should start with simple ICs without type feedback collection. Since this is quite huge task it'll be better to move step by step. At first I suggest to start with unary/binary op stubs then implement property lookup/store (it's still quite unclear for me how we will optimize here - v8 hidden classes approach or something else?).
The proposed algorithm for the first iteration (monomorphic binary/unary op ICs for Numbers without type feedback collection) is quite simple:
At first we have just generic dispatching stub we go through looooong sequence of conditions and try to seek appropriate specialized stub (uninitialized state).
Install specialized stub then call it (monomorphic state).
In specialized stub we perform simple assertions on operand type tags. If assertion fails we fallback to generic stub. If it passes assertions then we perform type-specific operation and tag result.
So, TODOs for first iteration for me looks like this:
Implement tagging for all primitives.
Figure out how to install/bailout stubs with minimal perfomance penalty. Using call with all the call-convention juggling doesn't look like a good option. However, otherwise we will need to recompile whole scope CFG with installed stub and re-run linearscan which is definitely sucks too. Any ideas?
Figure out if we can create somekind of IC generator instead of hand-written approach. As I see it: we can create hand-written stubs for same type operands (e.g. Int32 and Int32) with type-conversion place-holders. Then impement type conversion stubs. So, then we hit (Int32, String) we need generate (String, String) stub and inject (Int32->String) conversion stub for first argument.
Implement same-type stubs for Int32 and/or Smi
Implement same-type stubs for Double
Implement conversion stubs for Numbers
Update:
Benchmarks, benchmarks, benchmarks!
I think this should be enough to figure out techniques and approaches which we will use later. Then we can plan second iteration.
We need to collect type information in inline caches.
They should be stored in a Code space of
heap.js
. The ICs should be used only for a baseline compiler to gather the type info for optimising compiler.The text was updated successfully, but these errors were encountered: