On Wed, 4 Mar 2026 14:30:29 GMT, Andrew Dinn <[email protected]> wrote:
>>> Made an issue for tracking this here: >>> https://bugs.openjdk.org/browse/JDK-8377929 >> >> Mmm, but let's make sure we have a use for it. > > Yes, I think we should look into this in a follow up PR. For most numeric > kernels it makes sense to allocate and process blocks of vector registers -- > either a contiguous sequence or with a fixed +/- stride (as with the odd and > even subsequences) and that is why I defined VSeq to support that model. > However, with GPRs the more common allocation model is to make an individual > register live at some point in the code stream and then release it later on > to be reused for some other unrelated purpose, which means that we cannot > always rely on contiguity or a regular stride when operating on sequences of > registers. @theRealAph's pop/push allocator fits that common use case better. > We might still usefully implement a flavour of RSeq that populates its GPR > sequence from an allocator (relying on a destructor to free them) and then > define `rs_xxx` methods to perform operation `xxx` on RSeq inputs. We need to > work out the details before trying that. So if we do anything with GPRs in > this PR it should be using a pop/push allocator. Perhaps a general-purpose `RSeq` should contain a `RegSet`. We have everything we need to iterate over `RegSet`s, which are a very dense and efficient representation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2888684553
