| Main Updates from Last week: | |
| - First story change: Reducing the emphasis on AOT Baseline compilation, | |
| elevating the contribution of AOT ICs. Making the argument that a | |
| stuctured Inline Caching IR and separation from code and data enables the | |
| high coverage we see. AOT baseline compilation is kept around only as a | |
| contrast. | |
| - I'm still working out the arguments for section III. I will work on | |
| this tongiht to get your thoughts tomrorrow or later here. |
| Notes from code discussion: | |
| - Make AOT loading infallible. | |
| - Baseline interpreter must always be present. Other artifacts | |
| (ICs/ Baseline functions) can still fail to load since corpus is | |
| finite. More MOZ_ASSERTS. | |
| - Remove aot blob YAML field for "kind", becomes internally generated. |
Boostrapping Shell with AOT:
An empty AOTBaselineStub.S scaffold is checked in, but not attached as build
input. AOT dumps direct into AOTBaseline.S, which is a build input. First step
is: cp js/src/jit/AOTBaselineStub.S js/src/jit/AOTBaseline.S
I have some mozconfigs here, but the only option necessary is:
ac_add_options --enable-aot. Then ./mach configure && ./mach build
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.
| defining as a source of truth for future reference: | |
| jitless --no-jit-backend | |
| ------------------------------------ | |
| no dynamic executable memory | |
| aot-interp: --aot-interp --cache-ir-stubs=off | |
| ----------------------------------------------------- | |
| use the aot baseline interpreter but without inline cache stubs | |
| or aot-selfhosted code, even if the bootstrap contains it. |
problem:
We use TLS to load the &AOTIndirectionTable (TLS -> JSContext
-> JSRuntime -> JitRuntime -> AOTIndirectionTable) into a
BaselineFrame field, allowing AOT indirections to go through the
config:
| On AOT ICs: | |
| I'm beginning to appreciate how IC stubs resemble tiny | |
| programs. Compared to the deterministic codegen, like in | |
| blinterp and builtins, there is much more combinatorial | |
| variability. Some stub traits have proved more | |
| challenging than others to provide relocations for. | |
| Here is a brief, informal taxonomy, ordered from least | |
| to most difficult: |
A short update on the current AOT api:
We discussed previously whether ImmPtr is suitable
for AOT interception.
ImmPtr should be the right place to catch runtime ptrs
being emitted through the masm. However there are some
issues:ImmPtr(nullptr) prevent a verified
Running octane with and without AOT mode:
Benchmarking setup: