RFR: 8342601: AArch64: Micro-optimize bit shift in copy_memory

[John R Rose]

On Fri, 18 Oct 2024 18:35:02 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8342601](https://bugs.openjdk.org/browse/JDK-8342601)
> 
> Fix minor inefficiency in `copy_memory` by adding check before doing bit shift to see if we are able to do a move instruction instead. Change is low risk because of the low complexity of the change
> 
> Ran array copy and tier 1 on aarch64 machine
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/compiler/arraycopy          49    49     0     0   
> ==============================
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:tier1                     2591  2591     0     0   
>    jtreg:test/jdk:tier1                               2436  2436     0     0   
>    jtreg:test/langtools:tier1                         4577  4577     0     0   
>    jtreg:test/jaxp:tier1                                 0     0     0     0   
>    jtreg:test/lib-test:tier1                            34    34     0     0   
> ==============================

Thanks Dean.  If there is a specific forwarding mechanism for some moves but not all move-like instructions, then a micro-optimization like this is worth considering.  (We'd still want evidence from perf tests.)  I think it would belong inside the macro-assembler, though, so we don't play whack-a-mole finding all the places where we could reduce a quasi-move to a real forwardable move.  Also the comments documenting this decision belong in the macro-assembler, and not just in PR conversations or comments on random use-sites of the macro-assembler.

Again, for SPARC, we made the distinction between assembler and macro-assembler.  The assembler never did anything "smart", that was left to the macro-assembler.  Occasionally the same name would mean different things at the two levels of assembler.  That may or may not be good C++ practice.

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

PR Comment: https://git.openjdk.org/jdk/pull/21589#issuecomment-2423416746