Streamlined process for single instruction proposals

[dtig]

In the SIMD sync last week @lars-t-hansen noted that our current proposals process is quite heavy weight for adding single instruction proposals. On the Web API front, we have some precedence for nominal PRs, but this is not as straightforward for additions to the core spec, because we would want spec text, tests, interpreter and engine implementations even if we streamline the process. One approach I can think of is to have a stronger design consensus in Phase 1 for smaller proposals, and condense the meat of Phase 2, Phase 3 (spec text, tests, implementation) into one vote. In theory, this can also happen now, i.e. as long as the requirements are met, there is no reason not to have subsequent votes for Phase 2, Phase 3, Phase 4 as long as the requirements are met. Opening this issue to gather thoughts/feedback to see what process improvements we can make in this case.

[devsnek]

in TC39 we sometimes have proposals that jump from stage 0 to stage 2 directly, similarly to what you describe, because they meet the requirements and there is consensus. I think that could be reasonable in this venue as well.

[penzn]

Sorry, just found this, notification got lost in my inbox.

For simple proposals pretty much the entire English spec text can be covered in the initial presentation, which makes 0-1-2 trip mostly redundant. On the other hand, discussions at later stages can provide valuable feedback about the implementation. even if they technically can't affect the outcome - I think it is useful to get the feedback before the feature ships. Personally I feel like going directly to phase 2 is reasonable, but not sure we want to condense the latter phases.

[penzn]

Sorry, I went ahead and opened #880 to discuss this at a CG meeting. Also, do we want to apply this only to single-instruction proposals or any small proposals (for example there might be a few instructions doing related things)?

[lars-t-hansen]

Multiple instructions in one proposal packet should be OK. I think the bar should be that the instructions don't do anything "interesting" other than add new, fairly obviously useful, operations into the existing semantic framework.

For example, adding the relaxed FMA instructions to the SIMD MVP would not be a good fit for the fast-track process - because relaxed SIMD would be a new thing in that context. But once we have incorporated relaxed SIMD into the semantic framework through the normal process, new relaxed instructions could be added through the fast-track process.

Of the proposals that have shipped, sign extension and saturated float-to-int conversions might have been fast-trackable. None of the pending proposals seem to fit. I think of the fast-track process as a tweak that will benefit SIMD in particular, as it will allow us to ship SIMD improvements continuously rather than holding back a proposal in the fear that we've forgotten to include something.

[dschuff]

Another "small" proposal in-progress is extended-constexpr. In fact AFAIK the primary open question right now is how many new operations should be added. Maybe in that context, we could run the first batch through the full process and establish some kind of guideline for what we want the bar to be for new constexpr instructions. Then future additions could be fast-tracked.