[Bug tree-optimization/90387] [9/10 Regression] __builtin_constant_p and -Warray-bounds warnings

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it's the following passes (if you ignore that with -fopenacc we already
fold b_c_p during early opts):

      NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */);
      NEXT_PASS (pass_dce);
      NEXT_PASS (pass_stdarg);
      NEXT_PASS (pass_call_cdce);
      NEXT_PASS (pass_cselim);
      NEXT_PASS (pass_copy_prop);
      NEXT_PASS (pass_tree_ifcombine);
      NEXT_PASS (pass_merge_phi);
      NEXT_PASS (pass_phiopt, false /* early_p */);
      NEXT_PASS (pass_tail_recursion);
      NEXT_PASS (pass_ch);
      NEXT_PASS (pass_lower_complex);
      NEXT_PASS (pass_sra);
      /* The dom pass will also resolve all __builtin_constant_p calls
         that are still there to 0.  This has to be done after some
         propagations have already run, but before some more dead code
         is removed, and this place fits nicely.  Remember this when
         trying to move or duplicate pass_dominator somewhere earlier.  */
      NEXT_PASS (pass_thread_jumps);
      NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */);

There's constant propagation, value-numbering and complete loop unrolling
after inlining and before the above VRP pass plus one backwards jump
threading pass.  Note DOM applies the folding before jump threading.

I'd argue none of the above besides maybe loop-header copying should
expose more opportunities to fold b_c_p to true.  If SRA would do
then I'd call it a missed value-numbering opportunity (not to say
it's impossible).

So the risks of pessimization are IMHO low.  So if testing doesn't
reveal anything I'm going to do this change on trunk at least.