[llvm-dev] Looking for suggestions: Inferring GPU memory accesses
Madhur Amilkanthwar via llvm-dev
llvm-dev at lists.llvm.org
Sat Aug 22 08:38:03 PDT 2020
CUDA/GPU programs are written for a SIMT SIMD model, which means single
instruction, multiple threads and multiple data. Programmers write a single
program in such a way that each thread would execute it with different
data. So, a program is one physical copy but virtually it's run by several
threads so those grid/thread IDs are really meant for semantics of the
program. You can't replace thread specific variables with one thread ID.
Hence, I don't think what you're proposing would have much applicability in
real-world benchmarks like Rodinia.If you have a strong motivating example
then please provide a counter argument but in my experience, it won't be
In some corner cases, it would be useful but those would be a general case
of uniform code blocks.
On Sat, Aug 22, 2020 at 8:09 PM Ees Kee via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
> As part of my research I want to investigate the relation between the
> grid's geometry and the memory accesses of a kernel in common gpu
> benchmarks (e.g Rodinia, Polybench etc). As a first step i want to
> answer the following question:
> - Given a kernel function with M possible memory accesses. For how many of
> those M accesses we can statically infer its location given concrete values
> for the grid/block and executing thread?
> (Assume CUDA only for now)
> My initial idea is to replace all uses of dim-related values, e.g:
> and index related values, e.g:
> with ConstantInts. Then run constant folding on the result and check how
> many GEPs have constant values.
> Would something like this work or are there complications I am not
> thinking of? I'd appreciate any suggestions.
> P.S i am new to LLVM
> Thanks in advance,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev