On Thu, Dec 18, 2025 at 11:42 PM Andrew MacLeod <[email protected]> wrote: > > This was exposed by the new prange PTA code, but it does show up in > trunk, and back as far as GCC 13. > > GORI aggressively recomputes values when the inputs have changed on > conditi0nal branches. It avoids PHIS and statements with side effects, > but pretty much tries everything else. THis is too agressive as the > following test case shows: > > int foo (int x) > { > int y = __builtin_constant_p (x); > if (y) > isconst (y, x); > else > nonconst (y, x); > > if (x == 24) > { > /* Y should have the same value as earlier. */ > if (y) > isconst (y, x); > else > nonconst (y, x); > } > } > > y evaluates to [0, 0] as x is not a constant. However, in the > conditional branch x is known to be 24, and GORi recomputes y using this > values, and since [24, 24] is a constant, decides y is [1, 1] in this > block and promptly folds the condition and leaves a call to isconst > (1,24) instead of the correct nonconst (0, 24) > > This hasn't really been much of a problem because for most non range-op > statetmets, changing the inputs is not likely to change the resulting > range. Given that, its probably a waste of time to even try. > > This patch adds a fields to the gimple_range_op_handler class wihch > indicates whether the range_operator is recomputable or not, and > defaults them to yes. GORI then checks this method instead to determine > if recomputation should be attempted. > > Finally, the flag is set to false for the __builtin_constant_p handler > to avoid recomputing this. All the rest are OK I think. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?
OK. I suspect this also affects branches? > Andrew >
