[PATCH] D133214: [docs][RISCV] Document experimental extensions

[Alex Bradbury via Phabricator via llvm-commits]

asb added inline comments.


================
Comment at: llvm/docs/RISCVUsage.rst:97
+
+The primary goal of experimental support is to assist in the process of ratification by providing an existence proof of an implementation, and simplifying efforts to validate the value of a proposed extension against large code bases.  Experimental extensions are expected to either transition to ratified status, or be eventually removed.  The decision on whether to accept an experimental extension is currently done on an entirely case by case basis; if you want to propose one, attending the bi-weekly RISC-V sync-up call is strongly advised.
+
----------------
reames wrote:
> asb wrote:
> > Two thoughts here - if there's something you'd like to take from it in another revision of this patch that's great, but I'm also equally happy to land this as-is and continue work in follow-up patches.
> > 
> > I actually have a slightly different perspective on this. I think there's a second goal that is at least as important as supporting ratification, which is to help avoid duplicated or wasted effort on downstream forks and to avoid the problems (technical, potentially even licensing) that would ensue from later trying to merge a work from a long-lived downstream work that had been developed outside of LLVM's standard collaboration infrastructure and methodologies. 
> > 
> > I'd maybe clarify that our policies on experimental extensions as they stand only apply to extensions that are understood to be on a path towards ratification as a standard extension. Perhaps changing "The decision on whether to accept an experimental extension is currently done on an entirely case by case basis, though as it stands we've only agreed a policy that allows accepting such extensions if they are understood to be on a path towards eventual ratification as a standard RISC-V extension."
> > 
> > In case you hadn't seen it, see [here](https://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html) for more background.
> This gets complicated.  :)
> 
> In this review, I was specifically trying not to take a position on a couple of potentially controversial cases.  I do think we need to incorporate these, but I figured some discussion at a sync call was probably warranted.  I used the case by case wording to try to leave maximum flexibility until we'd had that conversation.
> 
> Case 1 - Extension on clear path to ratification.  This is the easy case.
> 
> Case 2 - Extension which has stalled on path to ratification with no significant uptake.  Ex: Several of the bitmanip variants.  Maybe we want to consider extensions with alternatives different than those without?
> 
> Case 3 - Vendor extension which is "done" and exists in real hardware.  Assume custom encoding space for this item.  
> 
> Case 4 - In development vendor extensions which haven't yet shipped.
> 
> Case 5 - Experimental extension which isn't ratified, but is shipped by a vendor.  With sub-cases for encodings chosen in  the custom space, and overlapping the general space.  (i.e. someone thought it was getting ratified and misjudged.)  
> 
> Case 6 - Vendor has a hardware bug, and we have a defacto vendor extension which overlaps with generic encoding space and maybe even claims generic extension support.  (Narrower in scope than 5, but probably the most annoying.)
> 
> My, not completely thought through, take is that we need to define a vendor extension policy, and then our stance on which experimental ones to accept gets broadened to include either on path to ratification or on path to vendor status.  
> 
> p.s. Thanks for the link.  I'd forgotten that.  Most of the discussion seemed focus on the mechanics (which this change documents), as opposed to the boundaries on what we should accept.  Unless I misread?  
You're right, the discussion was very focused on mechanics and on the very narrow topic of extensions believed to be on a path towards ratification. Extension being stuck in limbo (like a number of the bitmanip extensions) is also an eventuality that wasn't really considered.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133214/new/

https://reviews.llvm.org/D133214