Indeed; I agree it is not an implementation detail as potentially valid SPIR could be almost untranslatable to valid code running on a target without dedicated workgroup-local memory.<div><br></div><div>Micah: the problem can be distilled down to: __local variables in SPIR are represented as Constants (GlobalVariable : public Constant), but they are not in fact constant, for a device with no workgroup-local memory.</div>
<div><br></div><div>So it is valid SPIR, as the specification stands, to manipulate __local variables as Constants in a way that is extremely difficult to undo. That is, in order to transform SPIR to code that can run on a CPU, the GlobalVariable (which is a subclass of Constant) must be replaced with a dynamically calculated Value (which is not a subclass of constant).</div>
<div><br></div><div>The GlobalVariable can be used in ConstantExprs (of which there are many valid), and converting ConstantExprs to their Instruction corrollaries is very difficult in the general case.</div><div><br></div>
<div>Cheers,</div><div><br></div><div>James<br><br><div class="gmail_quote">On 27 September 2012 08:41, Pekka Jääskeläinen <span dir="ltr"><<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@tut.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/26/2012 08:21 PM, Villmow, Micah wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is my view that this is an implementation detail and not an issue<br>
with the SPIR spec. As SPIR is just a representation of a program in a<br>
portable manner, it is up to the consumer of SPIR to correctly set up<br>
the kernels based on the devices calling convention/ABI when the SPIR<br>
binary is loaded for that specific device.<br>
</blockquote>
<br></div>
The question was not about implementing the automatic locals (which is<br>
a device specific detail, like you correctly state), but enforcing LLVM IR<br>
for the automatic locals that potentially leads to illegal optimizations<br>
due to the inadequate semantics of global variables for this use.<br>
<br>
If SPIR enforces this type of bitcode for the automatic locals, it means when<br>
such optimizations do happen (the optimizations might be beneficial in<br>
general so they cannot be just disabled due to the SPIR flaw), the<br>
implementers have to work around them with kludges to implement the real<br>
automatic local semantics. What's worse, at some point there might be<br>
an optimization that is not easily worked around which makes this part of the<br>
SPIR specs look bad.<br>
<br>
Of course it's possible the constantGEP case was the only problem we will<br>
ever get from this issue, but I wouldn't rely on it in an IR standard<br>
specification if it's possible to avoid it.<br>
<br>
BR,<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Pekka<br>
</font></span></blockquote></div><br></div>