<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Add acquire/release flags to B3::MemoryValue"
   href="https://bugs.webkit.org/show_bug.cgi?id=162349">162349</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Add acquire/release flags to B3::MemoryValue
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>WebKit
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>WebKit Nightly Build
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>Normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P2
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>JavaScriptCore
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>webkit-unassigned&#64;lists.webkit.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>fpizlo&#64;apple.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>On ARM, we can mark loads and stores as having acquire or release semantics.  B3 should know about this.

I believe that this means that a load-acquire will have a write heap range.  This range must be non-empty.  This achieves both goals of acquire: it means that this load itself is not hoistable, and it means that other loads cannot be hoisted above this load, if they overlap with the write range.

I believe that this means that a store-release will have a read heap range.  This range must be non-empty.  The read range prevents other stores from being sunk below this one.  Also, the write range must be expanded to include anything that we don't want this store to be sunk to.

Maybe we can model acq/rel by just giving MemoryValue a second range?  That would be weird but it seems like it would work.  Alternatively, we would have a B3FencedMemoryValue, which includes the second range.  This second range would behave either as the read range or the write range depending on whether this was a load or a store.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>