RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized
Roland Westrelin
rwestrel at redhat.com
Mon Aug 13 14:38:02 UTC 2018
http://cr.openjdk.java.net/~roland/8209420/webrev.00/
Aarch64 emits a single instruction for volatile accesses that include
the required memory barriers. For this to work properly the aarch64
backend has to locate membars that go with a memory access to elide
them. This is currently implemented with some complicated pattern
matching that has proven fragile and painful to maintain. This change
introduces a new and robust process to locate membars and memory
accesses for volatile accesses.
An edge between the trailing membar and the Store or LoadStore that it
protects is now added. Membars are also tagged with what they are used
for. Going from a trailing membar to a leading membar (or the other way
around) uses a walk over the graph: from a trailing membar for a Store,
a walk up the graph until the membar that is tagged as LeadingStore
gives the leading membar for the Store.
For this to work, if a membar of a pair of leading/trailing membars is
eliminated the other membar of the pair must be eliminated too. That's
what some of the shared changes are for. Also, when a volatile store is
eliminated, so should its pair of membars. So while this is motivated by
aarch64, it benefits other platforms.
Roland.
More information about the hotspot-compiler-dev
mailing list