On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz <m.kr...@gsi.de> wrote:
>
> 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
after a simple grep, I see PAREN_EXPR is expanded to the common RTL
pattern. So it doesn't prevent any reassociation at the rtl level?
> > 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
> ──────────────────────────────────────────────────────────────────────────
--
BR,
Hongtao
