On Sat, 14 Feb 2026 10:36:06 GMT, Andrew Haley <[email protected]> wrote:
>> Made an issue for tracking this here: >> https://bugs.openjdk.org/browse/JDK-8377929 > >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2884118284
