Hi Cesar! On Mon, 20 Feb 2017 20:42:59 -0800, Cesar Philippidis <ce...@codesourcery.com> wrote: > This patch introduces a new -finform-parallelism flag to report any > detected parallelism encountered by the compiler. Initially, it's being > used to report how oaccdevlow partitions OpenACC loops. Currently, if > you want to extract this information, you need to compile the program > with -fdump-tree-oaccdevlow, then scan the tree dump for lines marked > Loop and decode the decimal bitmask that represents the parallelism. > This patch makes this process more user friendly by utilizing inform > messages to highlight the directives inside the source code, and clearly > print out the associated parallelism. E.g. given > > !$acc parallel loop > do i = ... > !$acc parallel loop > do j = ... > > -finform-parallelism reports
(Actually that should report that an OpenACC parallel construct nested in another OpenACC parallel construct is not yet supported?) > inform-parallelism.f90: In function ‘MAIN__._omp_fn.0’: > inform-parallelism.f90:10:0: note: ACC LOOP GANG > !$acc parallel loop > > inform-parallelism.f90:12:0: note: ACC LOOP WORKER VECTOR > !$acc loop Thanks! > Unfortunately, because this oaccdevlow runs so late, the offloaded > function name doesn't match the one specified by the user. It's still useful. We can later look into how to preserve the "original name". > While working on this, I noticed that the fortran FE wasn't recording > the location of combined loop directives properly, so I fixed that bug. That's a separate bug fix, please. > I also removed an unused variable inside trans-openmp.c. Also a separate bug fix, please. In <87sho0c12q.fsf@euler.schwinge.homeip.net">http://mid.mail-archive.com/87sho0c12q.fsf@euler.schwinge.homeip.net>, I asked you to fix that one. > This patch still isn't complete because I found a similar bug in the c++ > FE. Thomas, before I fix that bug Again, a separate bug fix, please. > do you think this patch is worth > pursuing for gomp-4_0-branch or maybe even trunk in general? Definitely! > Ideally, we > can extend these diagnostics to report any detected loops inside kernels > regions. Right. > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > +@item -finform-parallelism > +@opindex finform-parallelism > +Report any parallelism detected by the compiler. Inside OpenACC > +offloaded regions, this includes the gang, worker and vector level > +parallelism associated with any @code{ACC LOOP}s. This option is disabled > +by default. I know Fortran likes to use upper case, but the generic GCC code uses lower-case names. > --- a/gcc/omp-low.c > +++ b/gcc/omp-low.c > +/* Provide diagnostics on OpenACC loops LOOP, its siblings and its > + children. */ > + > +static void > +inform_oacc_loop (oacc_loop *loop) > +{ > + const char *seq = loop->mask == 0 ? " SEQ" : ""; > + const char *gang = loop->mask & GOMP_DIM_MASK (GOMP_DIM_GANG) > + ? " GANG" : ""; > + const char *worker = loop->mask & GOMP_DIM_MASK (GOMP_DIM_WORKER) > + ? " WORKER" : ""; > + const char *vector = loop->mask & GOMP_DIM_MASK (GOMP_DIM_VECTOR) > + ? " VECTOR" : ""; > + > + inform (loop->loc, "ACC LOOP%s%s%s%s", seq, gang, worker, vector); Likewise. Per <8737f68y3r.fsf@euler.schwinge.homeip.net">http://mid.mail-archive.com/8737f68y3r.fsf@euler.schwinge.homeip.net> I'm suggesting this to be done a bit differently: instead of "inform", this would then use the appropriate "-fopt-info-note-omp" option group output. If that's not yet there, possibly there could be some new flag added for "-fopt-info" to display the "rich" location, which will also print the original source code? Grüße Thomas