* Local optimization options @ 2020-07-04 9:30 Thomas König 2020-07-04 17:11 ` Richard Biener 0 siblings, 1 reply; 6+ messages in thread From: Thomas König @ 2020-07-04 9:30 UTC (permalink / raw) To: gcc mailing list, gfortran Hi, in Fortran, it would sometimes be useful to have a different optimization depending on whether we generate inlined code for intrinsics (where we know when it is OK to „go wild“) or user code, where we need to adhere (for example) to IEEE semantics unless otherwise instructed by the user. What could be a preferred way to achieve that? Could optimization options like -ffast-math be applied to blocks instead of functions? Could we set flags on the TREE codes to allow certain optinizations? Other things? Regards, Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Local optimization options 2020-07-04 9:30 Local optimization options Thomas König @ 2020-07-04 17:11 ` Richard Biener 2020-07-05 10:37 ` Thomas König 0 siblings, 1 reply; 6+ messages in thread From: Richard Biener @ 2020-07-04 17:11 UTC (permalink / raw) To: Thomas König, gcc mailing list, gfortran On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" <tk@tkoenig.net> wrote: >Hi, > >in Fortran, it would sometimes be useful to have a different >optimization >depending on whether we generate inlined code for intrinsics (where we >know when it is OK to „go wild“) or user code, where we need to >adhere (for example) to IEEE semantics unless otherwise instructed >by the user. > >What could be a preferred way to achieve that? Could optimization >options like -ffast-math be applied to blocks instead of functions? >Could we set flags on the TREE codes to allow certain optinizations? >Other things? The middle end can handle those things on function granularity only. Richard. >Regards, Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Local optimization options 2020-07-04 17:11 ` Richard Biener @ 2020-07-05 10:37 ` Thomas König 2020-07-05 11:15 ` Richard Biener 2020-07-05 14:37 ` Marc Glisse 0 siblings, 2 replies; 6+ messages in thread From: Thomas König @ 2020-07-05 10:37 UTC (permalink / raw) To: Richard Biener; +Cc: gcc mailing list, gfortran > Am 04.07.2020 um 19:11 schrieb Richard Biener <richard.guenther@gmail.com>: > > On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" <tk@tkoenig.net> wrote: >> >> What could be a preferred way to achieve that? Could optimization >> options like -ffast-math be applied to blocks instead of functions? >> Could we set flags on the TREE codes to allow certain optinizations? >> Other things? > > The middle end can handle those things on function granularity only. > > Richard. OK, so that will not work (or not without a disproportionate amount of effort). Would it be possible to set something like a TREE_FAST_MATH flag on TREEs? An operation could then be optimized according to these rules iff both operands had that flag, and would also have it then. Regards, Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Local optimization options 2020-07-05 10:37 ` Thomas König @ 2020-07-05 11:15 ` Richard Biener 2020-07-05 14:37 ` Marc Glisse 1 sibling, 0 replies; 6+ messages in thread From: Richard Biener @ 2020-07-05 11:15 UTC (permalink / raw) To: Thomas König; +Cc: gcc mailing list, gfortran On July 5, 2020 12:37:58 PM GMT+02:00, "Thomas König" <tk@tkoenig.net> wrote: > >> Am 04.07.2020 um 19:11 schrieb Richard Biener ><richard.guenther@gmail.com>: >> >> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" ><tk@tkoenig.net> wrote: >>> >>> What could be a preferred way to achieve that? Could optimization >>> options like -ffast-math be applied to blocks instead of functions? >>> Could we set flags on the TREE codes to allow certain optinizations? >>> Other things? >> >> The middle end can handle those things on function granularity only. >> >> Richard. > >OK, so that will not work (or not without a disproportionate >amount of effort). Would it be possible to set something like a >TREE_FAST_MATH flag on TREEs? An operation could then be >optimized according to these rules iff both operands >had that flag, and would also have it then. Since -ffast-math has effects on operations (-freciprocal-math) and on Operands (-fsignalling-nans) I think we'd need both and a single flag isn't enough. I guess parts of -ffast-math could be represented on a per stmt basis already, -fno-trapping-math for example could be TREE_NO_TRAP and the corresponding gimple flag. And yes, it would be very desirable to have all semantics fully represented in the IL rather than influenced by global flags. But then also optimization passes have to be careful to track state on that level. Richard. > >Regards, Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Local optimization options 2020-07-05 10:37 ` Thomas König 2020-07-05 11:15 ` Richard Biener @ 2020-07-05 14:37 ` Marc Glisse 2020-07-06 7:42 ` Richard Biener 1 sibling, 1 reply; 6+ messages in thread From: Marc Glisse @ 2020-07-05 14:37 UTC (permalink / raw) To: Thomas König; +Cc: Richard Biener, gcc mailing list, gfortran On Sun, 5 Jul 2020, Thomas König wrote: > >> Am 04.07.2020 um 19:11 schrieb Richard Biener <richard.guenther@gmail.com>: >> >> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" <tk@tkoenig.net> wrote: >>> >>> What could be a preferred way to achieve that? Could optimization >>> options like -ffast-math be applied to blocks instead of functions? >>> Could we set flags on the TREE codes to allow certain optinizations? >>> Other things? >> >> The middle end can handle those things on function granularity only. >> >> Richard. > > OK, so that will not work (or not without a disproportionate > amount of effort). Would it be possible to set something like a > TREE_FAST_MATH flag on TREEs? An operation could then be > optimized according to these rules iff both operands > had that flag, and would also have it then. In order to support various semantics on floating point operations, I was planning to replace some trees with internal functions, with an extra operand to specify various behaviors (rounding, exception, etc). Although at least in the beginning, I was thinking of only using those functions in safe mode, to avoid perf regressions. https://gcc.gnu.org/pipermail/gcc-patches/2019-August/527040.html This may never happen now, but it sounds similar to setting flags like TREE_FAST_MATH that you are suggesting. I was going with functions for more flexibility, and to avoid all the existing assumptions about trees. While I guess for fast-math, the worst the assumptions could do is clear the flag, which would make use optimize less than possible, not so bad. -- Marc Glisse ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Local optimization options 2020-07-05 14:37 ` Marc Glisse @ 2020-07-06 7:42 ` Richard Biener 0 siblings, 0 replies; 6+ messages in thread From: Richard Biener @ 2020-07-06 7:42 UTC (permalink / raw) To: GCC Development; +Cc: Thomas König, gfortran On Sun, Jul 5, 2020 at 4:37 PM Marc Glisse <marc.glisse@inria.fr> wrote: > > On Sun, 5 Jul 2020, Thomas König wrote: > > > > >> Am 04.07.2020 um 19:11 schrieb Richard Biener <richard.guenther@gmail.com>: > >> > >> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" <tk@tkoenig.net> wrote: > >>> > >>> What could be a preferred way to achieve that? Could optimization > >>> options like -ffast-math be applied to blocks instead of functions? > >>> Could we set flags on the TREE codes to allow certain optinizations? > >>> Other things? > >> > >> The middle end can handle those things on function granularity only. > >> > >> Richard. > > > > OK, so that will not work (or not without a disproportionate > > amount of effort). Would it be possible to set something like a > > TREE_FAST_MATH flag on TREEs? An operation could then be > > optimized according to these rules iff both operands > > had that flag, and would also have it then. > > In order to support various semantics on floating point operations, I was > planning to replace some trees with internal functions, with an extra > operand to specify various behaviors (rounding, exception, etc). Although > at least in the beginning, I was thinking of only using those functions in > safe mode, to avoid perf regressions. > > https://gcc.gnu.org/pipermail/gcc-patches/2019-August/527040.html Note this tackles the dependency on fesetround and friends which is of course another issue (tracking FP control and exception state). > This may never happen now, but it sounds similar to setting flags like > TREE_FAST_MATH that you are suggesting. I was going with functions for > more flexibility, and to avoid all the existing assumptions about trees. > While I guess for fast-math, the worst the assumptions could do is clear > the flag, which would make use optimize less than possible, not so bad. Indeed going with tree/gimple stmt flags or alternate tree codes (PLUS_NONTRAP_EXPR?) isn't likely to scale for the myriads of FP behavior controls we have. So using an internal function sounds reasonable though, given your referenced patch above, one might want to think about that extra input (FP env) and output (FP state) those functions will have as well. Also extracting the important bits from "fast-math" and thorougly documenting semantics of what flags we use would be required. To prevent too many bad effects on optimization one might think of using regular PLUS_EXPR when global flags match the specific ones on a internal-function ... Btw, instead of using the _Complex and __real/__imag trick for multiple defs we might want to go with more general SSA projections or allow multiple defs on functions at least. Richard. > -- > Marc Glisse ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-07-06 7:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-04 9:30 Local optimization options Thomas König 2020-07-04 17:11 ` Richard Biener 2020-07-05 10:37 ` Thomas König 2020-07-05 11:15 ` Richard Biener 2020-07-05 14:37 ` Marc Glisse 2020-07-06 7:42 ` Richard Biener
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).