llvm dev - Aug 2014 - [LLVMdev] [RFC] OpenMP offload infrastructure

On 08/11/14 01:03 PM, Das, Dibyendu wrote:
> I didn’t see SPIR discussed anywhere.
This isn't OpenCL and depending on OpenCL for OpenMP may not really make 
sense. While I have my own opinions - If you feel strongly that it will 
help enable higher performance somewhere please list those reasons.
----------
More specifically
LLVM has a native AMD dGPU backend that is tightly coupled to the 
compiler. Unlike other platforms which use things like PTX or other 
byte-codes. Those platforms lose performance or have to work-around not 
having hw level details. Assuming this is done correctly it would be a 
disservice to emit SPIR instead of native codegen. (Imagine JAVA JIT vs 
C performance)

This also keeps everything in the open..

In my experience - people don't use OpenMP because they want so-so 
performance.. and with Exascale this will be increasingly important..

Storing llvm-ir in the fat binary may have the same performance issues mentioned
below. The fat binary discussed in the proposal has provision for storing the
isa/llvm-ir. My point is instead of llvm-ir it shd be something like spir.


----- Original Message -----
From: "C. Bergström" [mailto:cbergstrom at pathscale.com]
Sent: Monday, August 11, 2014 04:15 AM Central Standard Time
To: Das, Dibyendu
Cc: Sergey Ostanevich <sergos.gnu at gmail.com>; llvmdev at cs.uiuc.edu
<llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] [RFC] OpenMP offload infrastructure

On 08/11/14 01:03 PM, Das, Dibyendu wrote:
> I didn’t see SPIR discussed anywhere.
This isn't OpenCL and depending on OpenCL for OpenMP may not really make 
sense. While I have my own opinions - If you feel strongly that it will 
help enable higher performance somewhere please list those reasons.
----------
More specifically
LLVM has a native AMD dGPU backend that is tightly coupled to the 
compiler. Unlike other platforms which use things like PTX or other 
byte-codes. Those platforms lose performance or have to work-around not 
having hw level details. Assuming this is done correctly it would be a 
disservice to emit SPIR instead of native codegen. (Imagine JAVA JIT vs 
C performance)

This also keeps everything in the open..

In my experience - people don't use OpenMP because they want so-so 
performance.. and with Exascale this will be increasingly important..

On 08/11/14 07:32 PM, Das, Dibyendu wrote:
> Storing llvm-ir in the fat binary may have the same performance issues
mentioned below. The fat binary discussed in the proposal has provision for
storing the isa/llvm-ir. My point is instead of llvm-ir it shd be something like
spir.
Ok - so lets see some data.

#1 Benchmarks showing at least SPIR dgemm/sgemm performance
#2 Some logical explanation why all the extra work for SPIR when LLVM IR 
is native

Basically besides an opinion or because it's "shiny" some solid 
technical reason.

I hate to repeat myself, but again.. why on earth would a solution which 
is closed source be preferred over llvm ir...