This is the mail archive of the gcc-patches@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: Initial submission of OpenACC support integrated into OpenMP's lowering and expansion passes


Hi!

Again, I'm sorry for the late answer.


On Fri, 8 Nov 2013 13:55:24 +0400, Dmitry Bocharnikov <dmitry.b@samsung.com> wrote:
> > > This is in contrast to Samsung's work, who are implementing OpenACC
> > > separately from the existing OpenMP support.
> > I'm not fully agree that this in contrast to things are taking place in
> > [openacc-1_0-branch]. The main reason for keeping middle-end and back-
> > end solutions far from GOMP is the understanding of OpenACC semantics
> > and unclear understanding of what should be done to generalize support
> > of accelerators in GCC. OpenACC and OpenOMP has some semantically
> > differences, but such things matters only for middle-end and further
> 
> I suppose that there is a misunderstanding in OpenMP and OpenACC 
> compatibility.

Well, not exactly a misunderstanding, but I just didn't address the
differences yet, as I first wanted to get something that basically works,
even if not yet according to the OpenACC standard's precise details, and
then later work on extending/reworking the compiler and runtime library
(relying on what already exists in libgomp) to properly implement what
both OpenMP and OpenACC require.

> OpenMP standard specifically states [...]

> On the other hand, OpenACC standard [...]

> Moreover, there is at least one commercial implementation that already 
> performs data dependency
> checking and feedback to user results of loop parallelization. However, in its 
> current state OpenMP
> implementation framework does not provide any means to do data dependency 
> checking.
> Would be it useful, if GCC implementation will be worse in that sense?

The "right" interpretation of the standards is certainly something we
should be discussing (and can also talk to the OpenACC committee, and
other OpenACC implementors), but I propose this to be an iterative
process, once the basic infrastructure is all there, and then by example
of (for example) specific testcases argue what should be done, how the
standard should be laid out.


GrÃÃe,
 Thomas

Attachment: pgp0jQ28rBbFc.pgp
Description: PGP signature


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