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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

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

[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  ---
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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
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

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to jos...@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

[joseph at codesourcery dot com]

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

--- Comment #1 from 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.