This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Terminology (was: Ping Re: [gomp4] Dumping gimple for offload.)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Ilya Tocar <tocarip dot intel at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, gcc <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, bernds at codesourcery dot com, nathan at codesourcery dot com
- Date: Mon, 25 Nov 2013 18:01:56 +0100
- Subject: Re: Terminology (was: Ping Re: [gomp4] Dumping gimple for offload.)
- Authentication-results: sourceware.org; auth=none
- References: <CAFiYyc3xJ2HWpds5fwe1HAnxzvQVbjdyL8zAK-4CfkchnBbH+g at mail dot gmail dot com> <20130925132924 dot GA122388 at msticlxl7 dot ims dot intel dot com> <CAFiYyc37RRjoeUfcg+N7g7Qo43YDtTa0kDJJ_fs--452eueH3g at mail dot gmail dot com> <20130926172127 dot GA41768 at msticlxl7 dot ims dot intel dot com> <20131003160507 dot GA116670 at msticlxl7 dot ims dot intel dot com> <CAFiYyc0P83gCjLKj6q=h4inyB2pLcYmL_NhUA+i=4s1Fx7Vy-g at mail dot gmail dot com> <20131114095226 dot GA128413 at msticlxl7 dot ims dot intel dot com> <CAFiYyc2oHNvv-MBy18OHgVU5g12StNU4LmZK+QeGpsoPj0w2mg at mail dot gmail dot com> <20131119095829 dot GA19301 at msticlxl7 dot ims dot intel dot com> <87pppompcq dot fsf at kepler dot schwinge dot homeip dot net>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Nov 25, 2013 at 05:13:25PM +0100, Thomas Schwinge wrote:
> > --- a/gcc/cgraphunit.c
> > +++ b/gcc/cgraphunit.c
> > @@ -2019,7 +2019,18 @@ ipa_passes (void)
> > passes->all_lto_gen_passes);
> >
> > if (!in_lto_p)
> > - ipa_write_summaries ();
> > + {
> > + if (flag_openmp)
>
> The following comment applies to several more instances in this patch:
> after the front end's parsing stage, we should now basically everywhere
> treat flag_openacc and flag_openmp the same. The idea is that all the
> existing OpenMP omp_* infrastructure in the middle end and following is
> now applicable to not only OpenMP but also OpenACC and any other
> "acceleration" mechanisms. Again, is there a better term to use instead
> of "acceleration" for describing the union of Cilk+, OpenACC, OpenMP, and
> similar techniques?
I don't think acceleration is a good term for everything say OpenMP does,
and calling OpenMP clauses acceleration clauses just because some other
standards decided to copy/modify a subset of the OpenMP syntax is weird.
>
> Also, would it then make sense to define a flag à la:
>
> #define flag_acceleration (flag_openacc | flag_openmp)
>
> ..., and begin using that everywhere after the front ends where
> flag_openmp is currently used?
We certainly can have some helper macros, but flag_openacc | flag_openmp
isn't the right definition of all of them, right now we have
flag_openmp, flag_enable_cilkplus (misnamed, should be really
flag_cilkplus), flag_openacc and flag_openmp_simd. For some things
(e.g. related to offloading, you want flag_openacc | flag_openmp,
for others, e.g. SIMD, you want flag_openmp | flag_openmp_simd |
flag_cilkplus, for others some different combination. So flag_acceleration
would be certainly misleading.
> Also here, the "target" tag is confusing in that "target" typically has a
> different meaning in the compiler context -- while this one here is used
I agree that target word there is weird.
> for implementing OpenMP's target construct, what it technically does
> should be described by .gnu.offload_gimple_ or somthing similar. (Note
> that also the LTO term is no longer really applicable, as we're not
> neccessarily doing link-time optimization here, but instead rather just
> use the GIMPLE dumping ("offloading") infrastructure that happens to
> already be implemented in GCC's LTO support.
But LTO is right here IMHO, we are streaming the LTO bytecode there, not
GIMPLE.
Jakub