[Bug ipa/88626] New: __builtin_constant_p should be as cheap as dead code for inlining purposes

[glisse at gcc dot gnu.org]

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

            Bug ID: 88626
           Summary: __builtin_constant_p should be as cheap as dead code
                    for inlining purposes
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

void h(int);
inline void f(int n){
#if 0
  bool b = ((n+2)*5-1)/3==1;
  if(__builtin_constant_p(b)&&b){
    h(3);return;
  }
#endif
  h(4);
  h(n);
}
void g(){f(7);}

Compiling with g++ -O2, we early-inline f into g, good. If I change #if 0 to
#if 1, we don't early-inline anymore because of the many instructions needed to
compute b. However, to a human, it is obvious that all this code to compute b
is "dead", it will never be emitted. If anything, the presence of
__builtin_constant_p should make this function a better candidate for inlining.

I don't know if this is a good example, maybe regular inlining is good enough
for such functions, and the analysis required for what I am asking would be
unsuitable for einline. I have a program where I introduced a
__builtin_constant_p shortcut in one function and noticed a 15% slowdown on the
total running time. Differences in inlining behavior are the most likely
explanation (and --param early-inlining-insns does help), so I quickly put a
testcase together. Feel free to close if it doesn't make sense.