llvm dev - Sep 2012 - [LLVMdev] [pocl-devel] [cfe-dev] 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

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
>

On 09/29/2012 12:00 AM, Villmow, Micah wrote:
> What would be ideal is to have the alloca instruction be able to allocate
> memory indifferent address spaces instead of only being in private.
This sounds like the most sensible and "correct" proposal so far.

If one wants to reuse the local space allocation overhead across multiple
WGs executing in the same thread, one would just need to find all the
allocas to the local AS and convert them, e.g., to function arguments that
are allocated by the WG launcher only once. And when creating a "multi-WI
WG
function", ensure the local allocas are shared across the WIs.

It sounds like a working and robust approach to me, although, of course, it
requires the LLVM IR update for the alloca instruction. I have no idea how
drastic update it would be.

-- 
--Pekka