[Bug c++/106654] [C++23] P1774 - Portable assumptions

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, we'll need something similar for OpenMP #pragma omp assume
(C/C++/Fortran).

I thought we could represent it in the IL as:
  if (.IFN_ASSUME ())
    {
      if (!cond)
        __builtin_unreachable ();
    }
where .IFN_ASSUME would eventually be folded into false.  We'd need to teach
the ranger etc. to take advantage of the bbs guarded by .IFN_ASSUME () as if
the condition would be true, the inliner to try to discover SESE regions
guarded by that condition and ignore them for size estimation purposes and
perhaps have somewhat higher code growth limits into those regions.
Richi doesn't like that.

Another possibility is to represent these as:
  .IFN_ASSUME (outlined_fun, args...);
where the cond expression would be outlined into an artificial function.
Ranger and other optimization passes then could try to evaluate the body of
outlined_fun with the assumption that the function returns true (if it returns
false, then it is UB).  We'd never emit the artificial outlined functions into
assembly nor debug info, but would inline into them and try to optimize them
after IPA.  Would be nice to have callgraph order their post IPA opts before
functions that .IFN_ASSUME reference them.
Either the outlined functions could be created in the FEs (e.g. for C++ we
could perhaps partly use code that we use for lambda capture discoveries), but
the disadvantage would be that we'd need to do it 3 times.
So another option would be some new GENERIC/GIMPLE statement kind used for
these and lower it only at say gimple lowering time (we have a precedent of
creating
outlined functions at ompexp time for OpenMP expansion).

Thoughts on this?  Aldy/Andrew, do you think it is something the ranger could
handle?