1742832 - [exploration] Consider a dedicated TableReg for (table 0)

Status: RESOLVED INVALID

(Core :: JavaScript: WebAssembly, task, P3)

Description

[Ryan Hunt [:rhunt] (on leave until early May)]

We have a dedicated HeapReg for (memory 0). We have experimented in the past with trying to drop HeapReg and rely on regalloc to give the heap base good allocations, but found that it didn't do a great job. Table accesses are not as hot, so it's likely this optimization would not perform as well. But it may be worth experimenting with to confirm this.

Comment 1

[Lars T Hansen [:lth]]

Summarizing from memory what we talked about yesterday:

We have a dedicated HeapReg for a memory; right now the only memory is memory 0, so it's an easy choice. Once we have multiple memories we will have some difficult choices to make about which memory should be so blessed. We already have multiple tables, so a dedicated table register will have to face this problem from the outset.

Table accesses probably aren't hot at all (until GC arrives) except for call_indirect. Once table accesses become hot, we would want to do bounds check elimination and probably null check elimination before experimenting with a dedicated register, as those checks likely swamp the one-instruction table pointer load.

While the forced reload of the HeapReg in a number of contexts is amortized over (typically) a great many memory accesses between every time such a reload is needed, the more likely case for tables is that there will be a very small number of table accesses for every table pointer reload - because various types of calls may force such reloads. We could measure this with a little instrumentation. Dmitry's work may impact the results. As the number of table accesses per reload approaches 1 (from above) the utility falls to zero. Once the number of accesses per reload falls below 1, the dedicated register has negative utility.

A register is a very precious resource, which is why we were trying to not pin HeapReg.

The register allocator did not do quite a good enough job on HeapReg but since a table register would be much less hot, it's somewhat likely that the register allocator can keep the table pointer in registers well enough that a dedicated register does not pay off.

Comment 2

[Lars T Hansen [:lth]]

This will not improve call_indirect (indeed it will slow it down), so moving to GC.

Comment 3

[Ryan Hunt [:rhunt] (on leave until early May)]

I think this is pretty unlikely to be useful.