Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"
On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote: > I wonder if a relatively easy starting point would be enabling the > declaration of do concurrent construct variables: > > do concurrent (integer :: i = 1:n) > > It’s a minor convenience and less exciting than adding locality specifiers > but possibly a good first exercise. > > > Damian I've already implemented 95% of the above. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 Unfortunately, the last 5% will take me too much time, which I don't have at the moment. Problems arise from the parsing of an iterator is shared by do current, forall, implied-do, and good old do-loops. For the first 3, 'i' is a control variable and is a statement entity (i.e., in the namespace of construct). To do a type spec in one of these cleanly, it would be prudent to either define a namespace for the construct or to use a shadow variable. The shadow variablei, which I was leaning towards, would replace the above with something like do concurrent (integer :: _i = 1:n) '_i' cannot conflict 'i', but this requires walking the execution block of the construct and replacing 'i' with '_i'. Perhaps, starting with the patch in PR96255 would be gentle intro to gfortran hacking. -- Steve
Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"
I wonder if a relatively easy starting point would be enabling the declaration of do concurrent construct variables: do concurrent (integer :: i = 1:n) It’s a minor convenience and less exciting than adding locality specifiers but possibly a good first exercise. Damian On Thu, Feb 23, 2023 at 07:08 Tobias Burnus wrote: > Hi, > > and welcome to the GCC / gfortran community. > > On 23.02.23 14:15, varma datla via Fortran wrote: > > I am willing to contribute to the project idea "Fortran – DO CONCURRENT". > > I hope the following helps a bit – it is admittedly a bit chaotic, but I > try to write something cleaner later. > > But to have something to think of and to startwith, it should be > sufficient: > > I think there are two parts to it: First, to add the changes of newer > Fortran to gfortran and then to actually use them to generate > concurrently running code. (Internally, gfortran currently handles 'do > concurrent' to run mostly like a normal loop – except that it annotates > the loops are independent. – Real parallelization would be useful, > however.) > > If you want to see examples, see do_concurrent_1.f90 to > do_concurrent_6.f90 in gfortran's testsuite, i.e. > gcc/testsuite/gfortran.dg/ in the GCC sources. That's at > > https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gfortran.dg;hb=refs/heads/master > / But it is best to download GCC yourself via Git as described at > https://gcc.gnu.org/git.html > > I want to note that the DO CONCURRENT syntax also permits a mask > argument, like in 'do concurrent (i=1:5, j=1:5, (i/=j))' where the last > argument selects a subset. > > For the Fortran standard, see https://gcc.gnu.org/wiki/GFortranStandards > > Fortran 2018 (= 18-007r1) adds for locality specifiers: LOCAL, > LOCAL_INIT, SHARED and DEFAULT(NONE). > > Fortran 202x alias 2023 adds 'reduce' as in 'do concurrent (i = 1, n) > reduce(+:a, b, c) reduce(max:d, e, f)' > > I think the first step is to add parsing support for those new features, > i.e. store them, check for issues (diagnostic) and then fail with a > 'sorry not yet implemented'. > > The next step would be to implement LOCAL/LOCAL_INIT for running on the > host. > > And then, finally, would be to translate into code which can then be run > concurrently. I was thinking of mapping it internally to OpenMP or > OpenACC, to be toggled via a commandline option like > -fdo-concurrent=. > > * * * > > I think the first step would be to download GCC and build it. Something > like "git clone" as described above, then "mkdir build" (some > directory); "cd build" and then "../configure --prefix=where-to-install" > followed by "make -j12" and "make install". The "-j12" runs 12 build > jobs in parallel. How much to use depends on your system. > > You probably need to install some development versions of libraries such > as ISL, gmp, mpfr and mpc. If you don't have them readily, an option is > to run ./contrib/download_prerequisites to download those and build them > automatically alongside GCC. > > So far for now. If you have questions, please ask. — And I will try to > write something more structured later. > > Tobias > > -- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 Münch > <https://www.google.com/maps/search/:+Arnulfstra%C3%9Fe+201,+80634+M%C3%BCnch?entry=gmail=g>en; > Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, > Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB > 106955 > > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 Münch > <https://www.google.com/maps/search/:+Arnulfstra%C3%9Fe+201,+80634+M%C3%BCnch?entry=gmail=g>en; > Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, > Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB > 106955 >
Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"
Hi, and welcome to the GCC / gfortran community. On 23.02.23 14:15, varma datla via Fortran wrote: I am willing to contribute to the project idea "Fortran – DO CONCURRENT". I hope the following helps a bit – it is admittedly a bit chaotic, but I try to write something cleaner later. But to have something to think of and to startwith, it should be sufficient: I think there are two parts to it: First, to add the changes of newer Fortran to gfortran and then to actually use them to generate concurrently running code. (Internally, gfortran currently handles 'do concurrent' to run mostly like a normal loop – except that it annotates the loops are independent. – Real parallelization would be useful, however.) If you want to see examples, see do_concurrent_1.f90 to do_concurrent_6.f90 in gfortran's testsuite, i.e. gcc/testsuite/gfortran.dg/ in the GCC sources. That's at https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gfortran.dg;hb=refs/heads/master / But it is best to download GCC yourself via Git as described at https://gcc.gnu.org/git.html I want to note that the DO CONCURRENT syntax also permits a mask argument, like in 'do concurrent (i=1:5, j=1:5, (i/=j))' where the last argument selects a subset. For the Fortran standard, see https://gcc.gnu.org/wiki/GFortranStandards Fortran 2018 (= 18-007r1) adds for locality specifiers: LOCAL, LOCAL_INIT, SHARED and DEFAULT(NONE). Fortran 202x alias 2023 adds 'reduce' as in 'do concurrent (i = 1, n) reduce(+:a, b, c) reduce(max:d, e, f)' I think the first step is to add parsing support for those new features, i.e. store them, check for issues (diagnostic) and then fail with a 'sorry not yet implemented'. The next step would be to implement LOCAL/LOCAL_INIT for running on the host. And then, finally, would be to translate into code which can then be run concurrently. I was thinking of mapping it internally to OpenMP or OpenACC, to be toggled via a commandline option like -fdo-concurrent=. * * * I think the first step would be to download GCC and build it. Something like "git clone" as described above, then "mkdir build" (some directory); "cd build" and then "../configure --prefix=where-to-install" followed by "make -j12" and "make install". The "-j12" runs 12 build jobs in parallel. How much to use depends on your system. You probably need to install some development versions of libraries such as ISL, gmp, mpfr and mpc. If you don't have them readily, an option is to run ./contrib/download_prerequisites to download those and build them automatically alongside GCC. So far for now. If you have questions, please ask. — And I will try to write something more structured later. Tobias -- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
