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

[Villmow, Micah]

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