PPC64 (part 113): Extend Load and Store nodes to know about memory ordering.

This is preparation for PPC64 integration: http://openjdk.java.net/jeps/175
This and following ppc64 changes will go into staging repository first and tested there: http://hg.openjdk.java.net/ppc-aix-port/stage/

Extend Load and Store nodes to know about memory ordering.

http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0113_opto-Extend_Load_and_Store_nodes_to_know_about_memory_ordering.patch


Some platforms support special load/store intsturctions to do memory ordering. These can be cheaper than a normal load/store instruction followed by an according memory barrier instruction. E.g., IA64 has ld.acq and st.rel, and PPC has the ld-twi-isync combination that is better than 'ld lwsync'.

HotSpots C2 inserts MemBarAcquire and MemBarRelease nodes into the IR if memory ordering is needed for a load/store operation. This is not well suited to use above described load/store instructions.

This change extends the load/store nodes of the IR by a field that indicates whether the load/store should do an acquire/release. The field is either set to 'unordered', if the node may be reordered with others, or to 'acquire' for Loads and 'release' for Stores. Checking for this field in the matcher allows to issue the proper operation.
If a platform does so, MemBarAcquire and MemBarRelease can be implemented empty, i.e., they basically serve to avoid reordering by the c2 compiler.

This change also removes default parameters from the affected load/store factory methods. Maintaining this change has shown very error prone if the defaults for the new field are ::unordered. If the default would be ::acquire/::release this would be safe, but then most places would need the parameter, anyways.