RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized

[Tobias Hartmann]

Hi Roland,

I've submitted some testing and the build fails on Sparc due to:
jib >
"/scratch/opt/mach5/mesos/work_dir/877d4fd1-1af0-4716-8f59-b83a1dad213c/workspace/open/src/hotspot/share/opto/memnode.hpp",
line 1156: Error: Identifier expected instead of "}".
jib >
"/scratch/opt/mach5/mesos/work_dir/877d4fd1-1af0-4716-8f59-b83a1dad213c/workspace/open/src/hotspot/share/opto/memnode.hpp",
line 1205: Error: Too many initializers for MemBarNode.
jib >
"/scratch/opt/mach5/mesos/work_dir/877d4fd1-1af0-4716-8f59-b83a1dad213c/workspace/open/src/hotspot/share/opto/memnode.hpp",
line 1205: Error: Cannot use Compile* to initialize MemBarNode.
jib >
"/scratch/opt/mach5/mesos/work_dir/877d4fd1-1af0-4716-8f59-b83a1dad213c/workspace/open/src/hotspot/share/opto/memnode.hpp",
line 1216: Error: Too many initializers for MemBarNode.
jib >
"/scratch/opt/mach5/mesos/work_dir/877d4fd1-1af0-4716-8f59-b83a1dad213c/workspace/open/src/hotspot/share/opto/memnode.hpp",
line 1216: Error: Cannot use Compile* to initialize MemBarNode.
jib >
"/scratch/opt/mach5/mesos/work_dir/877d4fd1-1af0-4716-8f59-b83a1dad213c/workspace/open/src/hotspot/share/opto/memnode.hpp",
line 1226: Error: Too many initializers for MemBarNode.

I think the problem is a comma at the end of memnode.hpp:1155

Best regards,
Tobias

On 13.08.2018 16:38, Roland Westrelin wrote:
> 
> 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.
>