<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>