* Re: [patch] Add support for #pragma GCC unroll [not found] ` <5042915.qGEuR7vFt9@polaris> @ 2017-11-20 11:57 ` Bernhard Reutner-Fischer 2017-11-20 14:45 ` Steve Kargl 0 siblings, 1 reply; 4+ messages in thread From: Bernhard Reutner-Fischer @ 2017-11-20 11:57 UTC (permalink / raw) To: Eric Botcazou; +Cc: GCC Patches, Richard Biener, Mike Stump, gfortran On 20 November 2017 at 12:26, Eric Botcazou <ebotcazou@adacore.com> wrote: >> If anybody finds the time to push the corresponding Fortran changes then I'd >> be grateful. I won't have time for this until end of stage 1... >> >> https://gcc.gnu.org/ml/fortran/2015-02/msg00014.html > > OK, I'm going to merge it in the main patch. [CCing fortran@] Thanks alot in advance! > > -- > Eric Botcazou ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch] Add support for #pragma GCC unroll 2017-11-20 11:57 ` [patch] Add support for #pragma GCC unroll Bernhard Reutner-Fischer @ 2017-11-20 14:45 ` Steve Kargl 2017-11-20 20:22 ` Bernhard Reutner-Fischer 0 siblings, 1 reply; 4+ messages in thread From: Steve Kargl @ 2017-11-20 14:45 UTC (permalink / raw) To: Bernhard Reutner-Fischer Cc: Eric Botcazou, GCC Patches, Richard Biener, Mike Stump, gfortran On Mon, Nov 20, 2017 at 12:57:47PM +0100, Bernhard Reutner-Fischer wrote: > On 20 November 2017 at 12:26, Eric Botcazou <ebotcazou@adacore.com> wrote: > >> If anybody finds the time to push the corresponding Fortran changes then I'd > >> be grateful. I won't have time for this until end of stage 1... > >> > >> https://gcc.gnu.org/ml/fortran/2015-02/msg00014.html > > > > OK, I'm going to merge it in the main patch. > > [CCing fortran@] > Thanks alot in advance! The URL points to a nearly 3 year old patch. I noticed that there is no documentation of the new Fortran directive. Section 7.2 of gfortran.info should be updated. In particular, does '!GCC$ UNROLL 4' affect only the immediately following DO-LOOP or all DO-LOOPs that follow the directive until another 'GCC$ UNROLL ...' is found? How does this new directive interface with OpenMP and OpenACC? -- Steve ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch] Add support for #pragma GCC unroll 2017-11-20 14:45 ` Steve Kargl @ 2017-11-20 20:22 ` Bernhard Reutner-Fischer 2017-11-21 10:21 ` Eric Botcazou 0 siblings, 1 reply; 4+ messages in thread From: Bernhard Reutner-Fischer @ 2017-11-20 20:22 UTC (permalink / raw) To: Steve Kargl Cc: Eric Botcazou, GCC Patches, Richard Biener, Mike Stump, gfortran On 20 November 2017 at 15:45, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: > On Mon, Nov 20, 2017 at 12:57:47PM +0100, Bernhard Reutner-Fischer wrote: >> On 20 November 2017 at 12:26, Eric Botcazou <ebotcazou@adacore.com> wrote: >> >> If anybody finds the time to push the corresponding Fortran changes then I'd >> >> be grateful. I won't have time for this until end of stage 1... >> >> >> >> https://gcc.gnu.org/ml/fortran/2015-02/msg00014.html >> > >> > OK, I'm going to merge it in the main patch. >> >> [CCing fortran@] >> Thanks alot in advance! > > The URL points to a nearly 3 year old patch. I noticed > that there is no documentation of the new Fortran directive. > Section 7.2 of gfortran.info should be updated. In particular, > does '!GCC$ UNROLL 4' affect only the immediately following > DO-LOOP or all DO-LOOPs that follow the directive until another > 'GCC$ UNROLL ...' is found? How does this new directive interface > with OpenMP and OpenACC? The documentation for the directive is missing indeed. We can fix this during stage3. Currently the directive works on the whole function (see gfc_cfun_has_unroll()) and instructs the loop-optimizers to run on that function. The loop-optimizers will discover the ANNOTATE_EXPR and act accordingly. Richard B. already noted that the RTL unroller might do more than intended, see https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01468.html I expect updates to the C and C++ in this area to be reflected to Fortran too. The interaction with OpenMP and OpenACC in the Fortran FE is the same as in the other frontends, obviously. Eric's current respin of Mikes patch is here, FYI: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01452.html thanks, ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch] Add support for #pragma GCC unroll 2017-11-20 20:22 ` Bernhard Reutner-Fischer @ 2017-11-21 10:21 ` Eric Botcazou 0 siblings, 0 replies; 4+ messages in thread From: Eric Botcazou @ 2017-11-21 10:21 UTC (permalink / raw) To: Bernhard Reutner-Fischer Cc: gcc-patches, Steve Kargl, Richard Biener, Mike Stump, gfortran > The documentation for the directive is missing indeed. We can fix this > during stage3. Someone who speaks Fortran will have to write it down... > Currently the directive works on the whole function (see > gfc_cfun_has_unroll()) and instructs the loop-optimizers to run on > that function. gfc_cfun_has_unroll is superfluous and has already been dropped because the flag will be set by the middle-end, but this doesn't change the behavior. > The loop-optimizers will discover the ANNOTATE_EXPR and act accordingly. > Richard B. already noted that the RTL unroller might do more than > intended, see https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01468.html > I expect updates to the C and C++ in this area to be reflected to Fortran > too. Yes, it's a generic issue. -- Eric Botcazou ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-11-21 10:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3136854.5zjt3GTbhu@polaris>
[not found] ` <CAFiYyc1rKGUtEc8MEKetP7=sD6GXs9avKGsY3o0tjF-O1hpT1g@mail.gmail.com>
[not found] ` <585BCFAB-107C-402E-B17A-CBD0E39419F2@gmail.com>
[not found] ` <5042915.qGEuR7vFt9@polaris>
2017-11-20 11:57 ` [patch] Add support for #pragma GCC unroll Bernhard Reutner-Fischer
2017-11-20 14:45 ` Steve Kargl
2017-11-20 20:22 ` Bernhard Reutner-Fischer
2017-11-21 10:21 ` Eric Botcazou
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).