RFR: 8301769: Generational ZGC: Indirect access barriers are never elided

[Roberto Castañeda Lozano]

This changeset extends barrier elision analysis to handle atomic (x64, riscv, aarch64) and volatile (aarch64) memory access instructions. Offset-based addressing modes are unavailable or disabled for these instructions, which defeats the regular [address component analysis](https://github.com/openjdk/zgc/blob/c16d33431f13e927f40b1fde99c5877f5a5eca6e/src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp#L606-L617) (finding the base and offset of an address) that is central to barrier elision analysis. The changeset extends the address component analysis with special handling to detect and extract the component information from the inputs and Ideal type of the address computation node. The proposed extension relies on the fact that AddP-matched Mach nodes contain the base address in the same input slot, as [guaranteed by Matcher::ReduceInst()](https://github.com/openjdk/zgc/blob/c16d33431f13e927f40b1fde99c5877f5a5eca6e/src/hotspot/share/opto/matcher.cpp#L1838-L1841).

The changeset also adds additional test cases that exercise analysis of atomic accesses on arrays, with the goal of testing more complex address computations, and enables the tests in aarch64. @TheRealMDoerr, @RealFYang: please let me know if you want to try out the tests on the other ZGC-supporting architectures and enable them as part of this changeset or handle that later.

**Testing:** tier1-7 (x64 and aaarch64; linux, windows, and macosx; release and debug mode)

#### Alternative solutions

Three alternative solutions were explored and discarded in favor of this one:

- Re-enable addressing modes for x64 atomics by duplicating the ADL instruction rules (see [prototype](https://github.com/openjdk/zgc/compare/zgc_generational...robcasloz:zgc:JDK-8301769-duplicate-adl-rules)). This enables the regular address component analysis for x64 but does not improve the situation for the other architectures. Furthermore, it makes the ZGC-specific ADL code less maintainable.

- Re-enable addressing modes for x64 atomics by introducing an ADL construct (e.g. an "operand effect") to enforce that a certain operand is always assigned a distinct register from the other operands. This has the same effect as the above alternative without affecting the readability of the ZGC-specific ADL code, but it still does not solve the issue for the other architectures.

- Extend the address component analysis with special handling as in this changeset, but performing a local analysis of the input address computation node (see [prototype](https://github.com/openjdk/zgc/compare/zgc_generational...robcasloz:zgc:JDK-8301769-mach-analysis)). This has a similar effect as this changeset for x64 but is less effective for other architectures with simpler addressing modes such as aarch64, where address computations are sometimes performed in multiple steps.

An open question is whether the local scope of the regular address component analysis affects the effectiveness of barrier elision for regular (non-atomic, non-volatile) memory accesses in architectures with more limited addressing modes than x64.

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

Commit messages:
 - Clarify why we can extract the base address from AddP's mach implementation
 - Analyze indirect operands at the Ideal level
 - Enable barrier elision tests for aarch64
 - Simplify tests
 - Extend barrier elision tests with atomic array accesses
 - Update test expectations

Changes: https://git.openjdk.org/zgc/pull/13/files
 Webrev: https://webrevs.openjdk.org/?repo=zgc&pr=13&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301769
  Stats: 71 lines in 2 files changed: 54 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/zgc/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/zgc pull/13/head:pull/13

PR: https://git.openjdk.org/zgc/pull/13