RFR: 8318446: C2: optimize stores into primitive arrays by combining values into larger store

[Roger Riggs]

On Thu, 18 Jan 2024 15:23:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I probably wouldn't write with decreasing indices, no, and if it'd be a lot of complexity I can see that it's not worth it.
> 
> And while I'm not suggesting you need to care for big-endian _hardware_ it would be good to have microbenchmarks that explicitly use and write in big-endian. I guess these do get a similar speed-up with your patch, but some verification would be great. Big-endian is quite common in networking protocols after all.
> 
> If it helps testing and verification I'd say only enabling this optimization on little-endian HW is fine if you can't find hardware or delegate to others to verify correctness and that there are equivalent speed-ups. Someone maintaining a big-endian platform should be able to test and verify as a follow-up, which might be better to not block progress here.

There is an existing use case for descending indices though they are being done via method handles to handle latin1 and UTF16 charset, so not byte array accesses except inside the method handle. The String format optimizations assemble components right to left, it benefits conversions from binary to printable forms. The implementations of java.util.FormatConcatItem are in java.util.FormatItem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16245#issuecomment-1900753444