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.