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 10:27 +0200, Richard Biener wrote:
> On Mon, May 6, 2013 at 5:16 PM, Jeff Law <law@redhat.com> wrote:
> > On 05/06/2013 07:41 AM, Tobias Burnus wrote:
> >>
> >> Evgeny Gavrin wrote:
> >>>
> >>> What do you think about support of OpenACC 1.0
> >>> (http://www.openacc-standard.org/) in gcc?
> >>
> >>
> >> I like the idea - though, I wonder whether OpenMP 4.0's "target"* would
> >> be the better choice as it looks a bit more flexible and better defined.
> >> (Conceptually, they are very similar; I think the
> >> middle-end/back-end/library part would even be the same.)
> >
> > We're certainly hoping that OpenACC & OpenMP 4 & Cilk+ can share certain
> > parts of their implementations.  We're already seeing OpenMP 4 and Cilk
> > starting to converge on some stuff.
> >
> > In a perfect world, there'd only be one standard for this stuff.  That's not
> > likely, so I'd be happy with parsing/FE kinds of things being specific to
> > each standard with everything from initial gimple generation through the
> > optimizers being shared.  That may not ultimately be possible, but I think
> > that's the right way to look at the work.
> 
> We're going to look at supporting HSA from GCC

Could you elaborate on those plans?

>  (which would make it
> more or less trivial to also target openCL I think) and also hope to leverage
> parts of the GOMP infrastructure for this

Are you thinking about leveraging the compiler side of GOMP, or libgomp?
I can see reasons for the former, but I'm not sure the latter is the
best approach to support for HSA.

> (GOMP is currently the only
> way to annotate parallel regions, apart from autodetecting them).  If Cilk+
> and OpenACC provide additional ways of annotating parallel regions then
> it would be nice to have the middle-end see only a single consistent way
> of a parallel region.

I agree that having one way of annotating parallel regions or task in
code would be useful.  There's also the TM infrastructure, which isn't
about parallelism but very much about annotated regions with additional
constraints on code in the regions, etc.; so it might perhaps be useful
too.  I believe it's the latter that's important here (and HW
heterogeneity), not whether we want to execute them in parallel or not
(i.e., you don't need language constructs to support parallel
execution...).


Torvald



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