On July 5, 2020 12:37:58 PM GMT+02:00, "Thomas König" <t...@tkoenig.net> wrote: > >> Am 04.07.2020 um 19:11 schrieb Richard Biener ><richard.guent...@gmail.com>: >> >> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" ><t...@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
