This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: OpenACC support in 4.9


On Tue, 2013-05-07 at 13:00 +0400, Evgeny Gavrin wrote:
> Hi, all!
> 
>  > Which accelerators do you intent to handle? "Accelerator" is a rather
>  > broad term, covering DSPs, GPUs, Intel's MIC, ...
> The idea is to emit OpenCL from high-GIMPLE, for know. So, any device 
> that has OpenCL support can be utilized by ACC.
> Maybe, we'll be able to reuse some parts from graphite/opengpu projects, 
> but this is not clear for now.

I don't disagree that this could be useful for a proof-of-concept, but
I'm wondering whether this is really useful to our users in the long
term.  We don't have any OpenCL implementation in GCC, so if we'd use
OpenCL below OpenACC, we'd bring in dependencies to the OpenCL
implementation, and GCC's OpenACC support would be like a
close-to-frontend translation layer to an OpenCL implementation (with
probably a glue library component too).

Also, if the representation that we eventually want to have in GCC for
accelerators isn't quite like OpenCL, then we'd be translating OpenACC
to this representation back to OpenCL.

Perhaps the HSA efforts that Richard mentioned could be a useful
lower-level target too?  Samsung is listed as an HSA founding member;
are you involved with HSA?

>  > Is there a specific reason for targeting 1.0 instead of 2.0 (besides 2.0
>  > still being declared as a draft)?
> You've named the main reason why we're targeting OpenACC1 - it's stable 
> and it's a good starting point for the initial implementation. BTW, 
> OpenACC2 differs not much from the previous version. Major improvements 
> covers only runtime library.

True, most of the differences seems to be in the Data API and such.
However, when I last looked at the list of proposed changes, there is a
proposal for allowing for calling non-inlined code.  It seems that this
would need to be part of general accelerator support (unless you'd want
to *require* inlining and LTO).  Vectorization features such as Cilk
also have something similar ("elemental functions"), so there seems to
be a need for this.

BTW, what's the state of OpenACC in general?  OpenACC 1.0 has been
released, but I had a few open questions after reading it a while ago.
Is 1.0 supposed to be a first draft, or indeed something that's expected
to be stable and useful for a long time?

>  > - but I don't think anyone will work on OpenMP 4.0's 'target' feature
>  > soon as the enough work on the non-'target' features remains.
> OpenMP's 'target' is definitely inspired by OpenACC. So, I think it'll 
> be possible to reuse/share most of BE part from OpenACC implementation, 
> once it's finished.

I'd agree with Jeff regarding this aspect: Even if we can't get a single
language-level standard for this in practice, we should try hard to have
somewhat compatible semantics in the different standards, and have a
internal representation in GCC that can represent those semantics.  It
seems unlikely that we can or want to support several incompatible
semantics, or have several different sets of middle-end IRs for
accelerators.  Thus, for GCC, I believe that the semantics that we want
to support are an important open question; those will also be affected
by the targets that we want to support (whether hardware or sth like
OpenCL).

Torvald


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]