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

Villmow, Micah Micah.Villmow at amd.com
Fri Sep 28 14:00:17 PDT 2012


What would be ideal is to have the alloca instruction be able to allocate memory indifferent address spaces instead of only being in private.

Micah

> -----Original Message-----
> From: Pekka Jääskeläinen [mailto:pekka.jaaskelainen at tut.fi]
> Sent: Friday, September 28, 2012 1:17 PM
> To: James Molloy
> Cc: Villmow, Micah; Carlos Sánchez de La Lama; Ouriel, Boaz; pocl-
> devel at lists.sourceforge.net; 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
> 
> On 09/28/2012 07:45 PM, James Molloy wrote:
> > That would be a simple, reasonable restriction that would stop
> > potentially maliciously horrible test cases causing all CPU SPIR
> > clients to write upwards of a hundred lines of conversion code.
> 
> Are you proposing to disallow the use of an IR instruction type to
> *possibly* avoid problems from the (slight) misuse of another LLVM IR
> construct?
> 
> IMHO there should be a more robust solution that solves the misused
> construct instead of just trying to "put out the fires it creates". E.g.
> some sort of "thread local"-type of qualifier for the global which
> disallows certain optimizations. A new linkage type perhaps? Someone
> more familiar with the LLVM IR than me might have a better idea.
> 
> I understand that adding the automatic local as a kernel argument (in
> the specs) is too intrusive now given the existing implementations that
> do it otherwise, especially for those for which the semantics "happens"
> to be correct as is. That is, the currently popular GPUs with separate
> local/scratchpad memories.
> 
> Have a nice weekend,
> --
> --Pekka
> 






More information about the llvm-dev mailing list