On Tue, 2013-05-07 at 10:27 +0200, Richard Biener wrote: > On Mon, May 6, 2013 at 5:16 PM, Jeff Law <l...@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
