<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 10:51 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":619" class="a3s" style="overflow:hidden">Hi Sameer,<br>
<span class=""><br>
> On Jan 5, 2015, at 4:51 AM, Sahasrabuddhe, Sameer <<a href="mailto:Sameer.Sahasrabuddhe@amd.com">Sameer.Sahasrabuddhe@amd.com</a>> wrote:<br>
><br>
> Right. The second version of my patches fixes the bitcode encoding. But now I see another potential problem with future bitcode if we require an ordering on the scopes. What happens when a backend later introduces a new scope that goes into the middle of the order? If they renumber the scopes to accomodate this, then existing bitcode for that backend will no longer work. The bitcode reader/writer cannot compensate for this since the values are backend-specific. If we agree that this problem is real, then we cannot force an ordering on the scope numbers.<br>
<br>
</span>That’s an interesting consideration, and something I hadn’t thought of.  I’m unsure offhand of how much it matters in practice.  The alternative, I suppose, is having something like string-named scopes, but then we can’t do much with them at the IR level.<br></div></blockquote><div><br></div><div>This has me somewhat non-plussed as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":619" class="a3s" style="overflow:hidden">
<span class=""><br>
> So far, I have refrained from proposing a keyword for cross thread scope in the text format, because (a) there never was one and (b) it is not strictly needed since it is the default anyway. I am fine either way, but we will first have to decide what the new keyword should be. I find "allthreads" to be a decent counterpart for "singlethread" ... "crossthread" is not good enough since intermediate scopes have multiple threads too.<br>
<br>
</span>This actually raises another question.  In principle, the “most visible” scope ought to be something like “system” or “device”, meaning a completely uncached memory access that is visible to all peripherals in a heterogeneous system.  However, this is almost certainly not what we want to have for typical memory accesses.<br>
<br>
To summarize, a prototypical scope nest, from most to least visible (aka least to most cacheable) might look like:<br>
<br>
System  —>  AllThreads  —>  Various target-specific local scopes —> SingleThread<br>
<br>
If we wanted to go really gonzo, there could be a Network scope at the beginning for large-scale HPC systems, but I’m not sure how important that is to anyone.<br></div></blockquote><div><br></div><div>I probably *should* be in a position to be very interested in such a concept.... but honestly, I'm not. If I ever wanted to do something like this, I would just define the large-scale HPC system as the "system" and a single machine/node as some "local" scope.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":619" class="a3s" style="overflow:hidden">
<br>
As a related question, do we actually need the local scopes to be target specific?  Are there systems, real or planned, that *aren’t* captured by:<br>
<br>
[Network —> ] System  —>  AllThreads  —>  ThreadGroup —> SingleThread ?</div></blockquote></div><br>Sadly, I don't think this will work. In particular, there are real-world accelerators with multiple tiers of thread groups that are visible in the cache hierarchy subsystem.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm starting to think we might actually need to let the target define acceptable strings for memory scopes and a strict weak ordering over them.... That's really complex and heavy weight, but I'm not really confident that we're safe committing to something more limited. The good side is that we can add the SWO-stuff lazily as needed...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dunno, thoughts?</div></div>