As discussed in PR97445 we should optimize builtins_constant_p (var+cst) and similar cases.
Confirmed, the generic is X OP CST (for / and %: CST OP X) into X inside __builtin_constant_p. Though the question should we do this on the gimple level or before hand?
Implemented in match.pd it will cover both. SSA backprop would be the most natural classical pass candidate but that runs after IPA. The other candidate is of course forwprop where it would be "cheaper" (not so many new patterns to match in match.pd), "chewing" ops during re-processing of processed stmts.
We would certainly need to punt on gimple_could_trap_p assignments, as can be seen e.g. on static inline int foo (int x) { return __builtin_constant_p ((x + 32) / 0); } int bar (void) { return foo (35); } with -O2 -fno-early-inlining. Anyway, I'm actually not sure if it is safe to perform this change at all. Consider: int foo (int x) { if (x < __INT_MAX__ - 30) return 23; int y = x + 30; if (__builtin_constant_p (y)) return y; return 42; } with -O2 -fdisable-tree-evrp y is constant (__INT_MAX__), but x is certainly not constant.