https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #5) > To be precise, expand_expr_divmod uses get_range_pos_neg for that during > expansion (unless we'd e.g. somehow noted it in some very late pass before > expansion that the division ought to be expanded both ways and cost > compared), and get_range_pos_neg uses the global range of SSA_NAME only. In > order to optimize #c0 we'd need to query range with the use stmt and > enabling ranger in the pass (that is possible in some pass before expansion, > but doing it during expansion (which would be useful to other spots too, say > .*_OVERFLOW expansion) would need to deal with some basic blocks already > converted into RTL and others still at GIMPLE). Im working on a logging mechanism for ranges for GCC 15. Its possible that a side effect of this work could make some selective contextual ranges available from the global table after .. in which case we could get things like this as if ranger was running. My other question. so is the issue that unsigned divides are cheaper than signed divides? the global range of _2 is set: _2 : [irange] int [0, 715827882] Given the statements in .optimized are: <bb 4> [local count: 1073741824]: _2 = x_1(D) / 3; return _2; could we not actually conclude that the divide can be unsigned based on the result being positive and the divisor being positive? We have "simple" versions of fold_range() which would calculate _2 on the statement from the global value of x_1, but there aren't any simple versions of the operand calculators. It would be fairly trivial to provide one which, given the global value for _2, you could ask op1_range (stmt) and get back a value of [0, +INF] for x_1 at that statement. If that would help... THey are going to be added for GCC 15 anyway...
