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 Wed, May 8, 2013 at 10:12 PM, Torvald Riegel <triegel@redhat.com> wrote:
> 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?

The ultimate goal is to transparently offload computations to HSA, thus
have GCC generate HSAIL/BRIG code from GIMPLE and dispatch to the
HSA runtime.

>>  (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.

The plan is to first rely on OMP annotations to identify possible code regions
that can be offloaded.  As not all OMP annotated regions will be off-loadable
there will be a mix of HSA and OMP thread code running at the same time
which means there has to be synchronization between the two if you
consider for example

#omp parallel
  for (;;)
    ... HSA possible ..

#omp parallel
  for (;;)
    ... HSA not possible ...

#omp barrier

and you don't want to nest HSA inside OMP implementation-wise.  Thus
the idea is to teach libgomp that there is besides threads also HSA
machinery (it's an idea on paper, we'll see how that can work out).

>> (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...).

There is several pieces to the picture here - first is source level annotation
where we have multiple variants (OMP, Cilk+, ...?), second is annotation
on the GIMPLE level which is where we only should have one, third is
the code-generation where we will end up supporting many (HSA, openCL, ...),
and fourth is the runtime where having multiple ones will create the issue
with mixed operation (from a single source level annotation way), so I'd
prefer to have a single runtime targeted by GCC (but the runtime itself
eventually dispatching to HW specific runtimes).

Richard.

>
> Torvald
>
>


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