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:[email protected]] > Sent: Friday, September 28, 2012 1:17 PM > To: James Molloy > Cc: Villmow, Micah; Carlos Sánchez de La Lama; Ouriel, Boaz; pocl- > [email protected]; [email protected]; [email protected] > 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 > ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
