This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: [gomp4, openacc-1_0-branch] Re: OpenACC branch
- From: Dmitry Bocharnikov <dmitry dot b at samsung dot com>
- To: 'Thomas Schwinge' <thomas at codesourcery dot com>, 'Evgeny Gavrin' <e dot gavrin at samsung dot com>
- Cc: 'Viacheslav Garbuzov' <v dot garbuzov at samsung dot com>, i dot usmanov at samsung dot com, gcc at gcc dot gnu dot org, jakub at redhat dot com, iverbin at gmail dot com, michael dot v dot zolotukhin at gmail dot com, triegel at redhat dot com, kirill dot yukhin at gmail dot com, nathan at codesourcery dot com
- Date: Wed, 02 Oct 2013 14:17:56 +0400
- Subject: RE: [gomp4, openacc-1_0-branch] Re: OpenACC branch
- Authentication-results: sourceware.org; auth=none
- References: <008801cebae4$f2842760$d78c7620$%gavrin at samsung dot com> <874n93waf0 dot fsf at kepler dot schwinge dot homeip dot net>
Hi, Thomas!
>
> Unfortunately, even with that in place, I'm getting ICEs in LTO
> streaming (that is, the test cases specifying -flto GCC's testsuite),
> and also for trivial OpenACC code with -fopenacc, both for Fortran and
> C code.
This was fixed yesterday with exception of LTO which was not tested.
> As you said yourself (but what is of course totally fine at this early
> development stage), the code is not yet mature: there are TODOs for
> missing error checking, catching invalid usage of directives by users,
> generally robustness, and so on. We shall address these as we continue
> working on this.
Sure, it's true.
> A bit more "trivia": changes to contrib/gcc_update are missing for the
> generated files in liboacc, and these should be using the same Autoconf
> and Automake versions as the rest of GCC is.
It will be fixed soon.
> For gcc/tree.def and gcc/gimple.def I agree it makes sense to have
> codes specific to OpenACC instead of, for example, shoehorning
> OACC_PARALLEL into the existing OMP_PARALLEL (and then adding a flag to
> it whether it is an OpenACC or OpenMP parallel statement...). The only
> concept I can think of where it'd make sense to even there re-use the
> existing OpenMP codes would be if there was a distinct "context" inside
> which it's clear whether OMP_PARALLEL means an OpenACC or OpenMP
> parallel construct. But that's probably more complex than simply
> having separate codes. But, we can re-use
> gcc/gimple.h:gimple_statement_omp as basis for OpenACC codes, avoiding
> gcc/gimple.h:gimple_statement_acc,
> gcc/gsstruct.def:gimple_statement_acc.
There is a problem with this approach: gimple_statement_omp is based on gimple_statement_base,
but we need gimple_statement_with_memory_ops_base for gimple_statement_acc.
>
> The new gcc/diagnose-gotos.c should probably re-use/be merged with the
> existing omp-low.c:pass_diagnose_omp_blocks from which it duplicates.
Sure, it's planned.
> Your loop analysis and parallelization for OpenACC kernels constructs
> seems to be based on tree-parloops.c code, which should also be
> properly shared instead of duplicating it.
>
> In gcc/tree-inline.c:estimate_num_insns there is OpenACC cost
> management not re-using OpenMP's (which might make sense to do?) -- but
> I can't see acc_cost being initialized anywhere?
Yes, these are planned too.
Best wishes,
Dmitri Botcharnikov