Repository navigation
[RFC] versioning #72
Description
@gnzlbg suggested we start versioning this proposal in #35. Now that we have a large subset of the proposed instructions implemented and relatively stable in the toolchain and in V8, I think that versioning the proposal would be useful. Let me know if you like the plan outlined below or if you would like to see something different!
Goals of versioning
Having version numbers for the proposal will enable users to reason about what kind of SIMD instructions they will be able to use with a given version of LLVM and V8, and to ensure that their toolchain and engine agree on which instructions are available. This is a proposal for how versioning could work that will achieve those goals while minimizing the overhead for implementers.
Versioning the spec proposal
Once V8 and the toolchain have both implemented the features required for the new version of the spec, a branch of this repo will be created with content that matches exactly what was implemented and a github release will be tagged. This release will contain notes on which versions of LLVM, emscripten, and V8 support the new version. These notes may be updated over time and the release tag updated if bugs in the tools or engine are found and fixed, but development of the spec proposal will continue on the master branch and will not be cherry picked to release branches.
Versioning the tools and V8
To keep complexity and overhead to a minimum, the tools and V8 will only support the latest tagged version of the spec, which should be well tested, and tip-of-tree SIMD development, which will probably be more buggy. That means that users will need to use older tools and V8 if they want to use older spec versions, but note that this does not violate any of the goals of versioning. Versioning is only meant to make using and communicating about the SIMD spec easier, so there will be no guarantees about compatibility between different versions of the spec.
Open questions
When do we want to start versioning? One option is to start with what V8 and the tools currently implement, which would require deleting some current spec proposal content in the release branch. The other option is to start versioning once V8 and the tools catch up with the spec proposal. If there are no strong objections to deleting content in the release branch, I would prefer the former.
Does versioning the spec proposal run afoul of any W3C CG protocols? Hopefully not, since the versions will not come with any sort of guarantees and will not exist in the final proposal, but maybe @binji can shed some light on this.
Activity
binji commentedon Apr 4, 2019
I'm a little concerned about all the references to v8 here; we have other wasm implementations, so we shouldn't treat any one of them specially. As for versioning the spec -- I believe there are mechanisms to do this, but they're intended for features that have shipped. As long as the implementations provide functionality behind a flag, I suppose it's just "buyer beware" if someone tries to use it.
If we want to go forward with this, perhaps something lighter weight is possible. We could open an issue (or a gist, or maybe even add a new .md file), with all the information you describe. I don't think we need to branch this repo for that, I think providing the SHA of this repo should be enough.
The reason I'm hesitant to do anything too official is that we definitely don't want to encourage users to think that any part of an unfinished spec is stable. If they are experimenting with SIMD, that's fine, but they should expect that they may be broken in the future. That said, I understand that the best way to make progress here is for users to "kick the tires" on implementations, and that's more difficult if they are working with a continually moving target.
tlively commentedon Apr 4, 2019
Thanks for you input, @binji!
The only reason I reference v8 is because it is the only engine I am aware of that has any SIMD support. We would be thrilled if some other engine wanted to help us develop this proposal as well. All references to "V8" in this proposal could be replaced with "some engine."
The reason I suggested branching and tagging is because it is native to git, so it seems more lightweight than adding new files to master. I would be open to using tags and a tracking issue instead of github's releases mechanism, although I worry that issues tend to get buried and are not very discoverable.
I definitely don't want to do anything official at all. This is only meant to help users kick the tires. Maybe having github releases looks too official, in which case a tracking issue would be better. WDYT?
penzn commentedon Apr 4, 2019
Chakra does support SIMD, I am not sure about others.
penzn commentedon Apr 17, 2019
@tlively and @binji, Chakra supports most/all (I am pretty sure that all, but can double-check) of the instructions under
unimplemented-simd128in the toolchain:https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/BuiltinsWebAssembly.def
dtig commentedon Apr 23, 2019
Cc @littledan, as we recently talked about versioning.
tlively commentedon Apr 24, 2019
Closing since we decided to pursue a simpler documentation strategy implemented in #73