search for: 1032203

...t;> >> ...is caused by LLVM/Clang thinking >> >> they are buffers with a constant base which they eventually won't be in a >> parallel WG implementation. This triggers an issue I'm currently working >> on >> pocl: https://bugs.launchpad.net/**pocl/+bug/1032203<https://bugs.launchpad.net/pocl/+bug/1032203>because Clang generates >> constant GEPs for the local buffer accesses (even though in a parallel >> thread-safe implementation the local variables cannot be stored to >> constant >> locations). >> >> >> Su...

...lem description. > > ...is caused by LLVM/Clang thinking >> >> they are buffers with a constant base which they eventually won't be in >> a parallel WG implementation. This triggers an issue I'm currently >> working on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because >> Clang generates >> constant GEPs for the local buffer accesses (even though in a parallel >> thread-safe implementation the local variables cannot be stored to >> constant locations). >> > > Surely if you're passing in pointers to the kernel funct...

...rstand your problem description. > > ...is caused by LLVM/Clang thinking > > they are buffers with a constant base which they eventually won't be in a > parallel WG implementation. This triggers an issue I'm currently working on > pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because Clang generates > constant GEPs for the local buffer accesses (even though in a parallel > thread-safe implementation the local variables cannot be stored to constant > locations). > > > Surely if you're passing in pointers to the kernel function that differ > depen...

...s caused by LLVM/Clang thinking >>> >>> they are buffers with a constant base which they eventually won't be in a >>> parallel WG implementation. This triggers an issue I'm currently working >>> on >>> pocl: https://bugs.launchpad.net/**pocl/+bug/1032203<https://bugs.launchpad.net/pocl/+bug/1032203>because Clang generates >>> constant GEPs for the local buffer accesses (even though in a parallel >>> thread-safe implementation the local variables cannot be stored to >>> constant >>> locations). >>>...

..." 'function static' variables for the local buffers is caused by LLVM/Clang thinking they are buffers with a constant base which they eventually won't be in a parallel WG implementation. This triggers an issue I'm currently working on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because Clang generates constant GEPs for the local buffer accesses (even though in a parallel thread-safe implementation the local variables cannot be stored to constant locations). So, I wonder if this piece of SPIR specs might cause other similar problems (LLVM optimizing incorrectly due to the...

...9;t fully understand your problem description. ...is caused by LLVM/Clang thinking > they are buffers with a constant base which they eventually won't be in > a parallel WG implementation. This triggers an issue I'm currently working > on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because Clang > generates > constant GEPs for the local buffer accesses (even though in a parallel > thread-safe implementation the local variables cannot be stored to > constant locations). Surely if you're passing in pointers to the kernel function that differ depending on work...

...Hi, I don't fully understand your problem description. ...is caused by LLVM/Clang thinking they are buffers with a constant base which they eventually won't be in a parallel WG implementation. This triggers an issue I'm currently working on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because Clang generates constant GEPs for the local buffer accesses (even though in a parallel thread-safe implementation the local variables cannot be stored to constant locations). Surely if you're passing in pointers to the kernel function that differ depending on workgroup, then a GEP fro...

On 09/12/2012 10:30 PM, Villmow, Micah wrote: >> case there are better ways to do that (metadata) > [Villmow, Micah] I disagree, the 'kernel' keyword specifies a different > calling convention from functions that don't have it. So we need a calling > convention that maps to that. The ABI for a kernel is different than the > ABI for a non-kernel function. The regular

On Thu, Aug 8, 2013 at 12:49 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 07:09 PM, Justin Holewinski wrote: >> >> I like having such a guarantee available, but I hesitate to *require* >> metadata in the IR. Perhaps if the metadata doesn't exist the verifier >> assumes the casts are valid and the optimizers have to assume all

> -----Original Message----- > From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On Behalf > Of James Molloy > Sent: Wednesday, September 12, 2012 12:18 PM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu; Villmow, Micah > Subject: Re: [cfe-dev] [LLVMdev] SPIR provisional specification is now > available in the Khronos website >