[Bug c/59159] New: Need opaque pass-through as optimization barrier

[Bug c/59159] New: Need opaque pass-through as optimization barrier

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

            Bug ID: 59159
           Summary: Need opaque pass-through as optimization barrier
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org

(category:c because I am asking for a built-in, but this is more about
middle/back-end)

Since gcc doesn't support FENV, I often need to insert optimization barriers in
my code that hide things from gcc optimizers, so it doesn't perform constant
propagation, or replace x*-y with -x*y, or move operations across fesetround,
etc. Note that speed is still very important, doing a store/read on a volatile
variable (the most portable optimization barrier) can make the whole
application 15% slower.

One common way to do that is to use an inline asm like:
asm volatile ("", "+g"(x));
(4.9 is the first version where this doesn't ICE all over the place on x86, use
"+m" earlier)
so no code is emitted but the value of x is hidden from the compiler. However,
the "g" constraint doesn't include FP registers. Depending if the code is
compiled for power, sparc, itanium, arm or x86_64, I need to add either "d",
"e", "f", "w", or "x" (yeah, there aren't 2 using the same letter). It looks
like there isn't even a letter for x87 (PR 59157). Using the more general "+X"
is tempting but ICEs (PR 59155).

There is at least one case this inline asm approach can never handle optimally:
constants. We need the variable as asm output or it won't have any effect. But
the constants are in a read-only location that is not suitable for an output
operand, so with "+m" gcc copies the constant to another memory location.

Ideally, there would be a __builtin_opaque built-in that does the right thing
and I wouldn't have to think about it...

[Bug c/59159] Need opaque pass-through as optimization barrier

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote:

> propagation, or replace x*-y with -x*y, or move operations across fesetround,

Do you mean -(x*y)?  I don't see the problem with replacing x*-y with
-x*y (which is (-x)*y), in any rounding mode.

[Bug c/59159] Need opaque pass-through as optimization barrier

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #1)
> On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote:
> 
> > propagation, or replace x*-y with -x*y, or move operations across fesetround,
> 
> Do you mean -(x*y)?  I don't see the problem with replacing x*-y with
> -x*y (which is (-x)*y), in any rounding mode.

Yes, sorry, I meant -(x*y).

[Bug c/59159] Need opaque pass-through as optimization barrier

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-18
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, as you want to guard against propagation across FP state changes I'd
rather make that explicit (thus, not make it a generic no-op propagation
barrier).

Of course thinking about a better representation of FP state in the middle-end
would be better as requiring the user to pass every value through such a
built-in isn't a nice user interface (yeah, better than making up asms ...).

  __builtin_protect (...)

for a generic name,

  __builtin_protect_fenv (...)

for sth more specific.  Both need to be type-generic and only result in
no overhead when the argument and return value are registers - consider

  float f1, f2;
  foo (&f1, &f2);
  .. = __builtin_protect (f1);
  .. = __builtin_protect (f2);

which would still cause a redundant load that cannot be optimized until
RTL optimization at least.

I wonder whether a very early pass splitting functions at FENV clobber
points and preventing re-inlining would be a better solution in the end
(yeah, making them nested with all the optimization side-effects that
causes, which also means _very_ early as unnesting happens more or less
during gimplification - or you re-invent unnesting in parts at least).

[Bug c/59159] Need opaque pass-through as optimization barrier

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Or have a pass that automates your asm() barrier instrumentation for all values
that are life across a FENV affecting call.

[Bug c/59159] Need opaque pass-through as optimization barrier

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 18 Nov 2013, rguenth at gcc dot gnu.org wrote:

> I wonder whether a very early pass splitting functions at FENV clobber
> points and preventing re-inlining would be a better solution in the end

That sounds like a nasty hack, not a sensible solution for properly 
supporting exceptions and rounding modes.  For interval arithmetic you 
want code changing rounding modes (or using the FENV_ROUND pragma proposed 
in DTS 18661-1) to be handled reasonably efficiently rather than resulting 
in a split into separate functions (really, a function with FENV_ACCESS 
enabled should be inlinable into one without, though I could certainly 
imagine an initial implementation controlling flags only on a per-function 
basis and preventing inlining).

[Bug c/59159] Need opaque pass-through as optimization barrier

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
__builtin_assoc_barrier is being implemented
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578935.html That
should solve part of this.