RFR: 8279570: IGV: Add source/destination property for load and store nodes with an associated field
Tobias Hartmann
thartmann at openjdk.java.net
Thu Jan 13 07:50:33 UTC 2022
On Wed, 12 Jan 2022 10:22:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:
> This patch adds a source/destination property field in the "Properties" view for a load/store node associated with a field in IGV. This simplifies the analysis of graphs when dealing with multiple loads/stores from/to fields.
>
> For each node, we are trying to get the associated `ciField` (`get_field()`). This works fine for direct field load/stores nodes. However, when facing an array access, we need to find the actual node doing the field access to get the `ciField` from. For that purpose, I added an additional search based on pattern matching (`find_source_field_of_array_access()`). It follows the address input of a load/store to find the field `LoadN` (compressed oops) or `LoadP` (non-compressed oops) from which we can get the `ciField`.
>
> Example:
>
> iFld = 1; // StoreI 25 (not shown in graph)
> iArrFld[2] = 3; // StoreI 67
> x = iArrFld2[4][5]; // LoadI 138
>
> 
>
> 
>
> - `StoreI 25`: Can directly fetch the field `iFld` with `get_field()`.
> - `StoreI 67`: For the store to an array, we follow the address input `AddP 66` -> `46 CastPP` -> `29 DecodeN` -> `28 LoadN` to get the field `iFldArr` from `28 LoadN` (done in `find_source_field_of_array_access()`)
> - `LoadI 138`: Same as for `StoreI 67` but we repeat the loop in `find_source_field_of_array_access()` when reaching `LoadI 138` -> ... -> `104 LoadN` to get the field `iArrFld2` eventually from `70 LoadN`.
>
> I additionally ran the following sanity testing with a Hello World program:
>
> java -XX:-TieredCompilation -Xcomp -XX:+PrintIdealGraph -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml HelloWorld.java
>
> Thanks,
> Christian
Very nice!
src/hotspot/share/opto/idealGraphPrinter.cpp line 710:
> 708: if (base != NULL) {
> 709: if (base->Opcode() == Op_CastPP) {
> 710: // CastPP node could have been removed.
There could also be a `CheckCastPP` or multiple casts, right? I would suggest to use `Node::uncast`.
-------------
Marked as reviewed by thartmann (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7048
More information about the hotspot-compiler-dev
mailing list