llvm dev - Sep 2012 - [LLVMdev] [pocl-devel] [cfe-dev] SPIR provisional specification is now available in the Khronos website

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.

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.

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

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.

Cheers,

James

On 27 September 2012 08:41, Pekka Jääskeläinen <pekka.jaaskelainen at
tut.fi>wrote:
> On 09/26/2012 08:21 PM, Villmow, Micah wrote:
>
>> It is my view that this is an implementation detail and not an issue
>> with the SPIR spec. As SPIR is just a representation of a program in a
>> portable manner, it is up to the consumer of SPIR to correctly set up
>> the kernels based on the devices calling convention/ABI when the SPIR
>> binary is loaded for that specific device.
>>
>
> The question was not about implementing the automatic locals (which is
> a device specific detail, like you correctly state), but enforcing LLVM IR
> for the automatic locals that potentially leads to illegal optimizations
> due to the inadequate semantics of global variables for this use.
>
> If SPIR enforces this type of bitcode for the automatic locals, it means
> when
> such optimizations do happen (the optimizations might be beneficial in
> general so they cannot be just disabled due to the SPIR flaw), the
> implementers have to work around them with kludges to implement the real
> automatic local semantics. What's worse, at some point there might be
> an optimization that is not easily worked around which makes this part of
> the
> SPIR specs look bad.
>
> Of course it's possible the constantGEP case was the only problem we
will
> ever get from this issue, but I wouldn't rely on it in an IR standard
> specification if it's possible to avoid it.
>
> BR,
> --
> Pekka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120927/32d82738/attachment.html>

Hi guys,
> 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).
What about translating automatic locals to function scope pointers?
This will make handling of automatic locals and local pointer
arguments similar, which is desirable as they are just a way to
describe the same thing (I understand automatic locals as just a
simpler way to use local buffers than local arguments).

In fact, pocl converts automatic locals to implicit "extra" kernel
arguments and manages both cases the same way.

Carlos

Carlos,
 AMD's OpenCL implementation(both CPU and GPU) has worked for years with the
way SPIR represents locals. If there is problems with the representation then it
is an implementation issue. One of the issues with using extra kernel arguments
is that it requires extra validation and complexity at the runtime level that is
not needed if it is handled internally by the compiler. That being said, both
ways of doing it are equally valid, but the choice of which way to do it is a
implementation decision. I don't think it would be that difficult to lower
global variables to function arguments given SPIR representation.

Micah
> -----Original Message-----
> From: Carlos Sánchez de La Lama [mailto:csanchezdll at gmail.com]
> Sent: Friday, September 28, 2012 12:34 AM
> To: James Molloy
> Cc: Pekka Jääskeläinen; Ouriel, Boaz; pocl-devel at lists.sourceforge.net;
> Villmow, Micah; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: Re: [pocl-devel] [cfe-dev] [LLVMdev] SPIR provisional
> specification is now available in the Khronos website
> 
> Hi guys,
> 
> > 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).
> 
> What about translating automatic locals to function scope pointers?
> This will make handling of automatic locals and local pointer arguments
> similar, which is desirable as they are just a way to describe the same
> thing (I understand automatic locals as just a simpler way to use local
> buffers than local arguments).
> 
> In fact, pocl converts automatic locals to implicit "extra"
kernel
> arguments and manages both cases the same way.
> 
> Carlos