On Mon, 30 Mar 2026 17:24:42 GMT, Paul Sandoz <[email protected]> wrote:
>> Emanuel Peter has updated the pull request incrementally with one additional >> commit since the last revision: >> >> two changes for Paul > > We can either add documentation to package doc or to a separate HTML file in > the same package. But for this review I realize I am likely asking too much, > it would be better to consider that holistically. > > I wonder if we can remove footnote-like text such as "(Some platforms do > support a..."? and perhaps it is possible after the definitions to > compress/remove most of the discussion before we focus on the various > resizing operations, maybe provide a textual example for each, and then on to > the table of the examples that amplifies with more examples? @PaulSandoz Thanks for the online and offline comments! > I wonder if we can remove footnote-like text such as "(Some platforms do > support a..."? This was from @rose00 , so I have not yet dared to remove it. I think it also nicely explains the rationale behind part numbers. For example on NEON, we really currently can only use 64 and 128 bit vectors. That is a very narrow band, and makes casting less straight-forward: you need to think about inserting and selecting. With synthetic vector shapes we can probably get around this. Even vector splitting could help: casting from 128 bit to 512 bit would then automatically split the 512 bit one into 4 vectors on NEON. At that point, we may need to re-write some of these sections. @rose00 What is your opinion on this paragraph? Quoting the whole thing for reference: > (Some platforms do support a rich variety of vector shapes, and can also > natively express logical expansions and contractions of lanewise data, > transparently adjusting vector shapes on the fly. But not all platforms have > enough shapes to pull this off well. And in extreme cases a shape change is > physically impossible, because the logical result would be just too large or > too small to be matched by any available vector shape. So the Vector API only > changes shapes in a method documented as shape-changing, and the user must > supply the new shape explicitly.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/30113#issuecomment-4160044385
