https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to rguent...@suse.de from comment #4) > > What was definitely missing is consideration of POLY_INT_CSTs (and > variable polys, as I think there's no range info for those). > Ranger doesn't do anything with POLY_INTs, mostly because I didn't understand them. > We do eventually want to improve how ranger behaves here. I'm not sure > why when we do not provide a context 'stmt' it can't see to compute > a range valid at the SSA names point of definition? (so basically > compute the global range) The call looks like it doesn't provide the stmt. Without the stmt, all ranger will ever provide is global ranges. I think you are asking why, If there is no global range, it doesn't try to compute one from the ssa_name_def_stmt? Ranger does when it is active. Otherwise it simply picks up the global information from SSA_NAME_RANGE_INFO() Of course, if its a poly int, we don't actually support those... so all you will ever see is VARYING. Again, because I don't understand them. > Maybe there's another API to do that. But I thought it was convenient > to use range_of_expr as that also handles GENERIC expression trees > to some extent and those are common within SCEV. A range can always be calculated by simply calling fold_range from gimple-range-fold.h: // Fold stmt S into range R using range query Q. bool fold_range (vrange &r, gimple *s, range_query *q = NULL); if range_query is not provided, it'll simply use the current one. If you want to ensure its only global ranges, you call it with fold_range (r, SSA_NAME_DEF_STMT (name), get_global_range_query ());
