I've been revisiting some ideas around optimized builtins. Since the paper is de-emphasizing JITless as the primary contribution, it would be nice to have a small performance win. Ideally we find an optimization not previously possible without AOT infrastructure. For this reason I've revived the IC inlining idea under "Profile Guided Speculative Monomorphic IC Inlining". A bit of a word salad.
It was previously noted that 24/29 ICs are monomorphic for the Array.map builtin. If an IC is provably monomorphic, we may be able to inline it into the baseilne compiled builtin. However, doing this safely has some challenges:
-
How do we prove the IC is monomorphic? Proof would be required to inline the IC stub code without guards and CF fall through at the end. A source level hybrid type inference would be required. However, SM previously had hybrid TI and removed it due to complexities mentioned in the CacheIR paper.
Maybe we don't need to prove the IC is monomorphic, maybe we can just speculate, i.e inline but with guards remaining and bailout if the IC fails. This would be speculative inlining. With the right profiling workload, inspecting the IC state at dump time to identify monomorphic sites would be a high-quality signal. All truly monomorphic sites could identified, a sufficiently variable workload should sift out polymorphic sites.
Engineering / Design Challenges:
-
Inlining IC code requires a joint masm buffer for baseline compilation and CacheIR compilation. There is precedent set with Ion stubs. This should just be an engineering problem.
-
Where to store dynamic stub data? Likely a side table in the ICScript? Maybe there is some Ion Stub patterns to follow here too.
Other concerns:
- Inlined IC sites would be invisible to WarpOrcale, potentially makking Ion compiled builtins slower. Solution may be to shadow IC data so WarpOrcale can consume it. Even for monomorphic stubs, eliding the guard may be important for Ion perf.
Current status:
- Some preliminary work done w/ existing profiling infra to identify monomoprhic ics. There seems to be a singificant proportion of ICs appearing monomorphic (identified from a small generated builtins workload script)
[BaselineAOT] found 24/33 monomorphic IC profiles for 'map'
[BaselineAOT] found 26/35 monomorphic IC profiles for 'filter'
[BaselineAOT] found 18/40 monomorphic IC profiles for 'reduce'
[BaselineAOT] found 18/25 monomorphic IC profiles for 'forEach'
[BaselineAOT] found 17/24 monomorphic IC profiles for 'find'
[BaselineAOT] found 17/24 monomorphic IC profiles for 'findIndex'
[BaselineAOT] found 19/26 monomorphic IC profiles for 'some'
[BaselineAOT] found 19/26 monomorphic IC profiles for 'every'
[BaselineAOT] found 13/17 monomorphic IC profiles for 'flat'
[BaselineAOT] found 18/31 monomorphic IC profiles for 'FlattenIntoArray'
[BaselineAOT] found 3/3 monomorphic IC profiles for 'padStart'
[BaselineAOT] found 26/33 monomorphic IC profiles for 'String_pad'
[BaselineAOT] found 23/33 monomorphic IC profiles for 'repeat'
[BaselineAOT] found 19/25 monomorphic IC profiles for 'Substring'
[BaselineAOT] found 3/3 monomorphic IC profiles for 'padEnd'