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
