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

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot 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).