On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote:
> -ffast-math decomposes to quite some flag_* and those generally are not
> reflected into the IL but can be different per function (and then
> prevent inlining).

Is there any chance the "and then prevent inlining" can be eliminated? Because 
then I could write my own fast<float> class in C++, marking all operators with 
__attribute__((optimize("-Ofast")))...

> There's one "related" IL feature used by the Fortran frontend - PAREN_EXPR
> prevents association across it.  So for Fortran (when not
> -fno-protect-parens which is enabled by -Ofast), (a + b) - b cannot be
> optimized to a.  Eventually this could be used to wrap intrinsic results
> since most of the issues in the end require association.  Note PAREN_EXPR
> isn't exposed to the C family frontends but we could of course add a
> builtin-like thing for this _Noassoc ( .... ) or so.  Note PAREN_EXPR
> survives -Ofast so it's the frontends that would need to choose to emit or
> not emit it (or always emit it).

Interesting. I want that builtin in C++. Currently I use inline asm to achieve 
a similar effect. But the inline asm hammer is really too big for the problem.


-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research               https://gsi.de
 std::experimental::simd              https://github.com/VcDevel/std-simd
──────────────────────────────────────────────────────────────────────────

Reply via email to