1933659 - wasm: Make LT/SII inlining less aggressive

Status: RESOLVED FIXED

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

Description

[Julian Seward [:jseward]]

Experimentation with using loop depths as inputs to the inlining thresholds, as
proposed in bug 1930459 comment 0, did not produce useful results. However, the
numbers collected suggest that we could modestly reduce the aggressiveness of
inlining without impacting performance, and save some code space and Ion
compilation time as a result.

This patch:

• reduces the basic inlining thresholds by 20%

• increases the individual per-function limit by a factor of 10; it was set far
  too low before, and quite frequently cut off inlining of "normal" functions
  prematurely. The per-module limit remains unchanged.

• as a ridealong, in ModuleGenerator::finishModule, fixes somewhat nonsensical
  logic in the setting of the per-module limit.

These changes cause a small performance improvement for:
WASM_GC_BENCH/Barista-Old (pre Nov '24), WASM_GC_BENCH/Barista-New (Nov '24)
and EMBENCHEN/Box2D, and are perf-neutral for WASM_GC_BENCH/j2wasm. Bytecode
expansion ratios fall by between 8% and 41%.

Comment 1

[Julian Seward [:jseward]]

Numbers: 2nd best of 10 runs, Core i5-1135G7, Fedora 39.

------------------------------------------------------------------------

WASM_GC_BENCH/Barista-Old (pre Nov '24)

      p-t bytecode expansion caused by inlining
      |       bytes actually used for p-t code storage
      |       |       First frame:
      |       |       |   Frame average:
      |       |       |   |      cycles:u
      |       |       |   |      |        instructions:u
      |       |       |   |      |        |
OLD   196.2%  158543  81  0.113  1220.3M  2131.0M
NEW   155.0%  138568  80  0.111  1209.4M  2112.4M

------------------------------------------------------------------------

WASM_GC_BENCH/Barista-New (Nov '24)

      p-t bytecode expansion caused by inlining
      |       bytes actually used for p-t code storage
      |       |        FluteComplex.AverageFrame(RunTime):
      |       |        |
OLD   373.2%  3766675  14302 us
NEW   345.2%  3687159  14188 us

------------------------------------------------------------------------

WASM_GC_BENCH/j2wasm

      p-t bytecode expansion caused by inlining
      |       bytes actually used for p-t code storage
      |       |       (number printed at end)
      |       |       |       cycles:u
      |       |       |       |       instructions:u
      |       |       |       |       |
OLD   42.7%   518597  0.1887  45229M  116037M
NEW   33.8%   486432  0.1867  45299M  116165M

------------------------------------------------------------------------

EMBENCHEN/Box2D

      p-t bytecode expansion caused by inlining
      |       bytes actually used for p-t code storage
      |       |       "WASM RUN TIME"
      |       |       |    cycles:u
      |       |       |    |        instructions:u
      |       |       |    |        |
OLD   9.2%    90375   602  2639.0M  8176.4M
NEW   5.5%    88372   599  2634.7M  8169.4M

Comment 2

[Julian Seward [:jseward]]

Attachment: Bug 1933659 - wasm: Make LT/SII inlining less aggressive. r=rhunt.

Numbers collected during experimentation for bug 1930459 suggest that we could
modestly reduce the aggressiveness of inlining without impacting performance,
and save some code space and Ion compilation time as a result.

This patch, accordingly:

• reduces the basic inlining thresholds by 20%

• increases the individual per-function limit by a factor of 10; it was set far
  too low before, and quite frequently cut off inlining of "normal" functions
  prematurely. The per-module limit remains unchanged.

• as a ridealong, in ModuleGenerator::finishModule, fixes somewhat nonsensical
  logic in the setting of the per-module limit.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e6b0c296cae
wasm: Make LT/SII inlining less aggressive.  r=rhunt.

Comment 4

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/8e6b0c296cae