https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #21 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #19) > > While ranger has a range_on_exit API this doesn't work on GENERIC expressions > as far as I can see but only SSA names but I guess that could be "fixed" > given range_on_exit also looks at the last stmt and eventually defers to > range_of_expr (or range_on_entry), but possibly get_tree_range needs > variants for on_entry/on_exit (it doesn't seem to use it's 'stmt' context > very consistently, notably not for SSA_NAMEs ...). That would appear to be an oversight. That API has not been used very much for arbitrary generic trees. I think the original reason support for tree expressions was added was a "try this" for some other PR. It was simple to do so we lef tit in, but it never got any real traction. At least as far as I can recall :-) Currently, I think mosrt, if not all, uses of get_tree_range() are either !gimple_ssa_range_p() (commonly constants or unsupported types) or ssa_names on abnormal edges. For abnormal edges, we ought to be getting the global range directly these days instad of calling that routine. Then in get_tree_range (), we ought to be calling range_of_expr for SSA_NAMES with the provided context. I'll poke at that too. The support for general tree expressions changed the original intent of the function, and it should be adjusted. As for the on-exit/on-entry bits... we haven't had a need for entry/exit outside of ranger in the past. I had toyed with exporting those routines and making them a part of the official API for value-query, but hadn't run across the need as yet. Let me think about that for a minute. It can certainly be done. I guess we really only need an on-entry and on-exit version of range_of_expr to do everything. So if we end up with something like: range_of_expr (r, expr, stmt) range_of_expr_on_entry (r, expr, bb) range_of_expr_on_exit (r, expr, bb) And have that all work with general trees expressions.. That would solve much of this for you? > > Interestingly enough we somehow still need the > > > hunk of Andrews patch to do it :/ > That probably means there is another call somewhere in the chain with no context. However, I will say that functionality is more important than it seems. Should have been there from the start :-P.
