RFR: 8313402: C1: Incorrect LoadIndexed value numbering

[Aleksey Shipilev]

See the bug for more investigation. 

This manifests in current tests, if you run them with C1. The root cause for the failure is that we fold two `LoadIndexed` nodes, when one of them reads `char` from `byte[]` via `_getCharStringU` intrinsic, and another one reads `byte` normally. So we can fold the "char"-reading load with "byte" reading load, effectively reading the wrong thing. New regression test shows it: it would read "42" instead of full char.


$ build/macosx-aarch64-server-fastdebug/images/jdk/bin/java -XX:TieredStopAtLevel=1 -XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintIR0 -XX:+PrintValueNumbering Test8313402.java

. 8 0 i152 a141[i110](i144) (B) [rc]
...
. 7 0 i180 a162[i110] (C)
...
Value Numbering: LoadIndexed i180 equal to i152 (size 47, entries 27, nesting-diff 0)
``` 

GVN hash discriminates on `type()->tag()`, but that `ValueType` maps to the same `T_INT` for both `char` and `byte`! Instead of hashing on that, let's hash on the original element type instead.

Testing:
 - [x] New regression test fails without the fix, passes after the fix
 - [ ] Linux AArch64 fastdebug, `tier1`
 - [ ] Linux AArch64 fastdebug, `tier2`
 - [ ] Linux AArch64 fastdebug, `tier3`

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

Commit messages:
 - Initial fix

Changes: https://git.openjdk.org/jdk/pull/15091/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15091&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313402
  Stats: 59 lines in 2 files changed: 58 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15091.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15091/head:pull/15091

PR: https://git.openjdk.org/jdk/pull/15091