[15] RFR(S): 8238438: SuperWord::co_locate_pack picks memory state of first instead of last load
Christian Hagedorn
christian.hagedorn at oracle.com
Mon Feb 17 16:32:55 UTC 2020
Hi
Please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8238438
http://cr.openjdk.java.net/~chagedorn/8238438/webrev.00/
When processing a load pack in SuperWord::co_locate_pack(), we pick by
default the memory state of the last load. But if we find a store that
is dependent on an earlier load in the pack, then we need to pick the
memory state of the first load.
The current code, however, checks for each load 'l' if it has a
dependency on an earlier store instead of checking if a later store is
dependent on 'l' (regression since [1]). At [2], we start at the memory
state of the current load and walk the memory graph to the memory state
of the first load while checking dependency constraints. This wrongly
checks for store->load instead of load->store dependencies. For example,
in the test case [3], the load pack consists of LoadI 656, 652,... with
its memory states 657 StoreI (first_mem) and 653 StoreI, respectively.
When processing the second load in the pack, 652 LoadI, we go up the
memory graph to first_mem (657 StoreI). The dependence graph now tells
us that 652 LoadI is dependent on 657 StoreI. From that we make the
wrong conclusion that we need to pick the memory state of the first load
which results in a wrong execution for that test case.
The fix now first finds the last memory state. Afterwards, it walks the
memory graph from the last memory state to the memory state of each load
in the pack (but not beyond) while checking for any load->store
dependency constraint (as done before [1]).
Thank you!
Best regards,
Christian
[1] https://bugs.openjdk.java.net/browse/JDK-8233032,
https://hg.openjdk.java.net/jdk/jdk/rev/3b693618d084
[2]
http://hg.openjdk.java.net/jdk/jdk/file/27e87c000b16/src/hotspot/share/opto/superword.cpp#l2306
[3] Part of the IR of the test case:
https://bugs.openjdk.java.net/secure/attachment/86850/load_pack_memory.png
More information about the hotspot-compiler-dev
mailing list