Soft Freeze on new operation additions post Phase 3

[dtig]

As the SIMD proposal is now at Phase 3, and getting closer to standardization, I'd like to propose a soft freeze on operation additions so that implementations, and toolchains have the opportunity to implement and optimize the existing operations without too much churn.

The freeze does not include existing issues/PRs, and is only for new proposals. The rationale is that due to the nature of the SIMD proposal, it's possible to keep adding new operations and given that there is reasonable consensus (barring open issues) on the current proposal, it will be hard to progress in standardizing the proposal without some sort of a freeze.

This is a soft freeze as it is possible with more implementations getting up to speed, and more applications are using the current SIMD proposal that there are must-have operations, or semantics need to be tweaked. But the bar for these would be higher.

Some open questions -

1. Is a deadline for a soft freeze useful (as opposed to going in effect immediately)? I suspect not, as the proposal has already been under discussion for some time now and as it's not a hard freeze deadlines may be arbitrary and not useful.
2. What should the bar be? This seems hard to codify in very concrete terms, but my thoughts are that the bar here should be that this would be very hard to emulate without an addition to the Spec, and the alternatives if any will cause performance cliffs. Addition of operations would be discussed on a case-by-case basis.

I'll be pinning this issue as suggested in a previous meeting for visibility. Any thoughts/concerns about this approach?

[dtig]

This would also make it easier for having a consistent set of opcode numbers as proposed in #129 going forward.

[jan-wassenberg]

@dtig makes sense. I see no pressing need for a deadline/extension. Hard/expensive to emulate without spec change sounds like a reasonable bar to me.

[zeux]

I would propose something like:

• hard/expensive to emulate in absence of spec change
• well supported on 2+ major archs
• useful in 2+ important use cases

Obviously all of this is vague (what are important use cases? what's the threshold for emulation complexity? etc.) but I think the goal is to think very carefully about any new instructions and default to maintaining the current proposal since solidifying it is (arguably) more important than adding a new instruction. Agreed that the deadline doesn't seem necessary.

[tlively]

I like @zeux's idea for the threshold because it shares its axes of criteria with the current threshold and is simply stricter.

[dtig]

Thanks all, I also like @zeux's idea of introducing an explicit threshold, and we all seem to be in agreement that an explicit deadline isn't necessary. Are there other ideas or concerns about this? If not, my next steps will be to add some explicit wording about this into the README, or somewhere that's easy to find.

[arunetm]

Thanks @dtig for putting this together and thanks @zeux for suggesting the explicit thresholds, a general agreement on these will help to ensure consistent evaluation of the current outstanding issues/proposals. The criteria and thresholds are reasonable imo, any disagreements ?

Agree that no further explicit deadline is necessary as we were having this issue pinned and open for feedback. @abrown brought up a potential need for considering new instructions in rare cases, when current instruction semantics cannot be calibrated effectively for addressing the issues. Do we need a provision for these? @abrown anything to add?

[penzn]

I think there is a common consensus that we need to stick to some variant of the criteria @zeux proposed above (#203 (comment)):

• hard/expensive to emulate in absence of spec change
• well supported on 2+ major archs
• useful in 2+ important use cases

However I think we need a bit more clarity on those, especially on what we mean by important use cases. I think it is very easy to find examples of native instructions or matching intrinsics for most PRs, (not harder than demonstrating that proposed instructions would perform well in micro benchmarks). I would like to propose the following as minimum criteria for a use case:

• code (snippet from a software project)
• the project should compile to Wasm or be in the process of porting
• addition of proposed instruction(s) estimated to have measurable positive impact on performance

First bullet might sound obvious, but we do have PRs that either cite no use cases or refer to publications. With our current load of PRs approaching one per day, we need to think how realistic it would be to evaluate on actual code. I don't think that references to matching native intrinsics should be considered sufficient, unless that code is in the process of being ported to Wasm.

It is important that the project has a Wasm port, even experimental one (even one done by the person proposing the PR) and everybody can build that. I think we should actually go a step further and track the application in the proposal. This is nothing out of the ordinary, performance work is done like this in the "native compilation" world.