[LLVMdev] [RFC] Parallelization metadata and intrinsics in LLVM

[Raghavendra, Prakash]

Hi Hal

I was also looking at providing such a support in LLVM for capturing (both explicit and implicit)
parallelism in LLVM. We had an initial discussion around this and your proposal comes at the
right time. We support such an initiative. We can work together to get this support implemented
in LLVM.

But, I have a slight different view. I think today parallelism does not necessarily mean OpenMP
or SIMD, we are in the area of heterogeneous computing. I agree that your primary target
was thread-based parallelism, but I think we could extend this while we capture the parallelism
in the program.

My idea is to capture parallelism with the way you have said using 'metadata'. I agree to record
the parallel regions in the metadata (as given by the user). However, we could also give placeholders
to record any additional information that the compiler writer needs like number of threads,
scheduling parameters, chunk size, etc etc which are specific perhaps to OpenMP.

The point is that the same parallel loop could be targeted by another standard to accelerators today
(like GPUs) using another standard OpenACC. We may get a new standard to capture and target
for different kind of parallel device, which could look quite different, and has to specifically targeted.

Since we are at the intermediate layer, we could be independent of both user level standards like
OpenMP, OpenACC, OpenCL, Cilk+, C++AMP etc and at the same time, keep enough information at this stage
so that the compiler could generate efficient backend code for the target device. So, my suggestion is
to keep all these relevant information as 'tags' for metadata and it is up to the backend to use or
throw the information. As you said, if the backend ignores there should not be any harm in correctness
of the final code.

Second point I wanted to make was on the intrinsics. I am not sure why we need these intrinsics at the
LLVM level. I am not sure why we would need conditional constructs for expressing parallelism. These
could be calls directly to the runtime library at the code generation level.

Again, this is very good initiative and we would like to support such a support in LLVM ASAP.

Prakash Raghavendra
AMD, Bangalore
Email: Prakash.raghavendra at amd.com
Phone: +91-80-3323 0753

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120815/835e7457/attachment.html>