Bug 35423 - Implement OpenMP workshare
Summary: Implement OpenMP workshare
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: openmp, patch
Depends on:
Blocks: 42478
  Show dependency treegraph
 
Reported: 2008-03-03 14:27 UTC by Tobias Burnus
Modified: 2014-12-23 14:48 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-03-07 11:48:45


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-03-03 14:27:28 UTC
Jakub wrote:
> BTW, omp workshare is implemented the same as omp single and this is the
> first time I see somebody actually using that construct anywhere. I don't
> have plans to implement omp workshare more efficiently, at least in the
> foreseeable future. So ATM !$omp parallel workshare is just a fancy
> way to say something is not parallelized. It is standard conforming, but
> not going beyond that.

Seemingly it becomes more requested. The quote above comes from:
  http://gcc.gnu.org/ml/fortran/2008-02/msg00137.html
and it was requested also in
  http://gcc.gnu.org/ml/fortran/2008-03/msg00008.html
Comment 1 Jakub Jelinek 2008-03-06 11:20:38 UTC
This is not middle-end thing, all that is needed is change fortran FE to lower
(some forms of ) !$omp workshare constructs into some other standard worksharing construct than single, particularly into OMP_FOR or perhaps sometimes OMP_SECTIONS or OMP_SINGLE just for one or a couple of lines rather than the whole !$omp workshare.
I don't plan to work on this myself, but any of the numerous Fortran FE maintainers could do this, I can help with advice if needed.
Either code to expand the implicit loops in expressions will need to be duplicated, or tweaked (e.g. add a flag to them, which would result in OMP_FOR
loops being created rather than normal loops).
Comment 2 Tobias Burnus 2008-07-01 18:08:02 UTC
First patch: http://gcc.gnu.org/ml/fortran/2008-06/msg00281.html
Comment 3 Tobias Burnus 2008-08-13 20:57:53 UTC
Patch v1.1: http://gcc.gnu.org/ml/fortran/2008-08/msg00032.html
Comment 4 Francois-Xavier Coudert 2009-03-29 08:11:59 UTC
Has the second patch been reviewed? Has Vasilis completed his copyright assignment?
Comment 6 Jakub Jelinek 2009-04-20 11:00:24 UTC
Subject: Bug 35423

Author: jakub
Date: Mon Apr 20 10:59:59 2009
New Revision: 146397

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146397
Log:
	PR fortran/35423
	* trans.h (OMPWS_WORKSHARE_FLAG, OMPWS_CURR_SINGLEUNIT,
	OMPWS_SCALARIZER_WS, OMPWS_NOWAIT): Define.
	(ompws_flags): New extern decl.
	* trans-array.c (gfc_trans_scalarized_loop_end): Build OMP_FOR
	for the outer dimension if ompws_flags allow it.
	* trans.c (gfc_generate_code): Clear ompws_flags.
	* trans-expr.c (gfc_trans_assignment_1): Allow worksharing
	array assignments inside of !$omp workshare.
	* trans-stmt.c (gfc_trans_where_3): Similarly for where statements
	and constructs.
	* trans-openmp.c (ompws_flags): New variable.
	(gfc_trans_omp_workshare): Rewritten.

	* testsuite/libgomp.fortran/workshare2.f90: New test.

Added:
    trunk/libgomp/testsuite/libgomp.fortran/workshare2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-openmp.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/libgomp/ChangeLog

Comment 7 Tobias Burnus 2009-12-03 14:16:19 UTC
Items left to do:

* worksharing of other stuff (say FORALL)
[I have not check the patch, but possibly assignments in WHERE blocks could also profit from more work]

* dependency analysis ("the goal of dependency checking is to avoid unnecessary 
barriers by inserting NOWAIT clauses when safe.  Hopefully the functionality provided in dependency.c will be useful here")

(cf. http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01598.html)
Comment 8 Dominique d'Humieres 2014-12-23 14:48:15 UTC
This PR is more than five years old and seems (mostly) fixed. Any reason to keep it open?