<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 12/04/2013 05:25 PM, Andrew Trick
      wrote:<br>
    </div>
    <blockquote
      cite="mid:7EFAF76A-7A2F-4A75-BBB9-9AEDFEEC82A0@apple.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On Dec 4, 2013, at 5:19 PM, Matt Arsenault <<a
            moz-do-not-send="true"
            href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>>
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div style="font-size: 12px; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: auto; text-align: start;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
            0px;">On 12/04/2013 04:29 PM, Andrew Trick wrote:<br>
            <blockquote type="cite">On Dec 4, 2013, at 3:33 PM, Matt
              Arsenault <<a moz-do-not-send="true"
                href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>>
              wrote:<br>
              <br>
              <blockquote type="cite">On 11/11/2013 03:13 PM, Andrew
                Trick wrote:<br>
                <blockquote type="cite">On Nov 9, 2013, at 1:39 PM, Matt
                  Arsenault <<a moz-do-not-send="true"
                    href="mailto:arsenm2@gmail.com">arsenm2@gmail.com</a>>
                  wrote:<br>
                  <br>
                  <blockquote type="cite">On Nov 9, 2013, at 3:14 AM,
                    Chandler Carruth <<a moz-do-not-send="true"
                      href="mailto:chandlerc@google.com">chandlerc@google.com</a>>
                    wrote:<br>
                    <br>
                    <blockquote type="cite">Perhaps you're instead
                      trying to say that with certain address spaces
                      "noalias" (and by inference, "restrict" at the
                      language level) has a different semantic model
                      than other address spaces? While it's less
                      worrisome than the first interpretation, I still
                      don't really like it.<br>
                      <br>
                    </blockquote>
                    This sounds right. With the constant address space,
                    anything you do is OK since it’s constant. Private
                    address space is supposed to be totally inaccessible
                    from other workitems, so parallel modifications
                    aren’t a concern. The others require explicit
                    synchronization which noalias would need to be aware
                    of.<br>
                  </blockquote>
                  FWIW, it seems generally useful to me to have a
                  nomemfence function attribute and intrinsic property.
                  We should avoid memory optimization (and possibly
                  other optimization) across these regardless of alias
                  analysis.<br>
                  <br>
                </blockquote>
                I'm think I'll try implementing this. Ideally it would
                be parameterized over the address space, so it makes
                more sense for it to be a memfence attribute rather than
                a nomemfence. You would then have an arbitrary number of
                memfence(N) attributes for each required address space.<br>
              </blockquote>
              So for correctness, would we need to tag all functions
              with memfence(0..M) until we can prove otherwise? That
              seem heinous.<br>
            </blockquote>
            I was thinking the absence of it would mean no memfence in
            any address space, which is the current behavior. This adds
            the option of fencing.<br>
            <blockquote type="cite">Better to have an optional attribute
              that can be added to expose optimization. Is it important
              in practice to optimize the case of memfence(I) +
              nomemfence(J)?<br>
            </blockquote>
            I think it would be important for the GPU case. You never
            need a memfence for private address space / addrspace 0, but
            you frequently want them for local or global. The local or
            global writes can't be reordered, but it could be very
            beneficial to move the private accesses across fences which
            might help reduce register usage.<br>
            <br>
            <blockquote type="cite"> If so, is there a problem with
              nomemfence(N)?<br>
            </blockquote>
            nomemfence is the current assumption made on an arbitrary
            call, and it's the common case. Specifying the absence of a
            fence seems backwards of how this is used and more
            cumbersome to deal with. To match the current behavior, it
            would require littering nomemfence for any possible address
            space everywhere. In OpenCL you specify your fences, so it
            would be more straightforward to map that. If I have a
            memfence intrinsic, I just need to mark it with the fence
            attribute, and then propogate it to its callers. There would
            generally only be a few of them in any program compared to
            fenceless calls. To implement this with nomemfence, I would
            have to mark every function with at least 4 nomemfences, and
            remove them when encountering the memfence intrinsic.</div>
        </blockquote>
      </div>
      <div><br>
      </div>
      <div>Sure, but the program still needs to be correct if you skip
        attribute propagation.</div>
      <div>-Andy</div>
    </blockquote>
    <br>
    Is that actually a real concern? My main problem with nomemfence is
    how do you mark a function as not fencing any other address space
    you might care about around call sites? I suppose nomemfence without
    an address space could indicate nomemfence for any address space,
    but then that just restricts the problem to when you do have a few
    fenced address spaces. How do you know what other address spaces are
    relevant to be marked? Add a nomemfence for any address spaces
    encountered in functions with call sites? What if those in another
    module?<br>
  </body>
</html>