This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR83017 (fortran part)
On Fri, Nov 17, 2017 at 3:03 PM, Richard Biener <rguenther@suse.de> wrote:
> On Fri, 17 Nov 2017, Janne Blomqvist wrote:
>
>> On Fri, Nov 17, 2017 at 11:13 AM, Richard Biener <rguenther@suse.de> wrote:
>> > This patch changes the Fortran frontend to annotate DO CONCURRENT
>> > with parallel instead of ivdep.
>> >
>> > The patch is not enough to enable a runtime benefit because of
>> > some autopar costing issues but for other cases it should enable
>> > auto-parallelization of all DO CONCURRENT loops.
>> >
>> > Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for the fortran
>> > part?
>>
>> I recall some years ago there was discussion whether DO CONCURRENT
>> should be handled as "Ok to vectorize" or "Ok to parallelize using
>> threads", and I believe back then it was decided to play it safe and
>> just vectorize. Has this consensus changed now? And with this change,
>> are we now using threads, or both vectors and threads? And is it
>> enabled always, or only with -fopenmp, or some
>> -ftree-loop-parallel-whatever? And if the second, how does it interact
>> with openmp parallelization?
>
> It is only parallelized with -ftree-loop-parallelize, OpenMP processing
> comes first to I think it doesn't interfere here. The loops are still
> marked with ivdep as well and thus should enable vectorization.
Ok, sounds good then. Ok for my part.
For OpenMP, the thing that came to mind was that if you had an outer
loop parallelized with "omp parallel do", then an inner DO CONCURRENT
loop, hopefully you don't then get N*N threads? That is, does
-ftree-loop-parallelize use the thread pool that libgomp creates, or
does it create its own?
> The
> usual caveats may apply when trying to vectorize outlined loops
> (loops that have been parallelized).
>
> Was the "play safe" for correctness concerns or for optimization
> concern?
IIRC it was an optimization concern, if users assume DO CONCURRENT
means "vectorize" then they may use it for short loops where the
overhead of threads isn't worth it. Back then I recall it wasn't clear
what other compiler were going to do with DO CONCURRENT, thus merely
vectorizing was a safer option at the time. It seems that nowadays at
least Intel attempts to use threads for DO CONCURRENT only with
-parallel//Qparallel, which more or less matches what you're proposing
here. Which I guess is good for users in a performance portability
sense.
--
Janne Blomqvist