RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide.

[Lindenmaier, Goetz]

Hi David,

as reply to your comment on the bug:

Well, I sitll would need 2 different nodes, as on PPC we do
  MemBarAcquireWide --> lwsync
  MemBarReleaseWide --> lwsync
  MemBarVolatile      --> sync.
On Sparc, you even do 3 different operations.

Or should I name them MemBarFenceAcquire and MemBarFenceRelease?
This all depends a lot on the available instructions of the processors.
Therefore I think a really clean representation that, at the same time, allows
to find the cheapest set of instructions to express it on all
processors, is impossible.

Best regards,
  Goetz

PS:  Should I respond to comments in the bug right in the bug
or on the mailing lists?








From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: Montag, 18. November 2013 15:19
To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov
Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide.

Hi,

The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory ordering in various places. Some order a certain load/store with other operations. Inline_unsafe_fence() inserts MemBars that do not correspont to a memory operation. So far, the same nodes were used.

This change introduces MemBarAcquire/ReleaseWide to use where no dedicated load/store is ordered. With this change, these nodes can be matched differently, what is needed on PPC64.

When reviewing 8024921 (part 113) we decided to avoid #defines in inline_unsafe_fence() and to introduce new MemBar operations.

Please review and test this change.
http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/

Best regards,
  Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20131118/0e6fbbe8/attachment-0001.html