1320645 - Wasm baseline: Infrastructure to safeguard optimization applicability

Status: RESOLVED INACTIVE

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

Description

[Lars T Hansen [:lth]]

It is useful to measure (test suites, instrumentation) whether a test case continues to exercise the optimization that it was written to test.  The present bug focuses on the need for that in the wasm baseline compiler, but the problem really applies to Ion as well, and it would be useful if a general solution could be found.

One solution is to expose a counter for a pattern-matching optimization to the shell; the shell tests that a test case causes the counter to be increased during the run.  The initial patch here, inherited from bug 1286816, does that.  It works adequately for wasm (low-level input language that is minimally processed before the optimizer sees it) and the baseline compiler (simpleminded optimizations that don't combine in interesting ways).

Another solution that has been discussed on IRC is to instead expose a trace of operations to the shell and to pattern-match in this trace instead.  The simplest trace might be MASM operations: for the control optimization in bug 1286816, we would expect the trace /not/ to contain the cmp32Set operation, for example.  Many optimizations at the CodeGenerator level can probably be tested this way, for Ion.

MASM operations are an easy target because we can in principle generate a tracing masm the way we generate crash stubs for the None target.  (No doubt there are complications.)

Comment 1

[Lars T Hansen [:lth]]

Attachment: bug1320645-opt-check-infra.patch

Carrying f+ from Hannes on older bug.

Comment 2

[Lars T Hansen [:lth]]

Another situation came up in a couple of wasm baseline bugs, here we are not trying to ensure that an optimization triggers but that a certain code generation pattern is indeed exercised.

In bug 1322450 we have a test case that tests that a store that narrows from 32-bit or 64-bit to 8-bit works even when the register the value is in does not have a byte part (on x86-32).  In bug 1322288 we have a test case that tests that the join register is available for a value carried along a taken conditional branch whose condition uses operand registers that might easily be mapped to the join register.

Both test cases depend on internal register allocator details that could easily change, and indeed, in the case of the join register problem, are expected to change.

At a minimum we would like to know whether the test case continues to be applicable and realistic.  This is hard enough.  Even better we might be able to construct a test case on the fly (via some kind of reflection) that for sure exercises the desired code.

Comment 3

[Lars T Hansen [:lth]]

Attachment: bug1320645-baseline-profiling-infra.patch

This is a more generic version of the same profiling infrastructure.  I'm factoring it because it turns out to be generally useful, see eg bug 1313576.

Comment 4

[Lars T Hansen [:lth]]

Not really planning to land any part of this, but the code is super useful, so keeping the bug open at P5 for now.

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 6

[Lars T Hansen [:lth]]

I don't think we'll use this code. A similar idea has been implemented to track SIMD shuffle optimizations; most likely we would build on that if we were to implement more optimization tracking.