On 5/24/21 9:34 PM, Martin Sebor wrote:
On 5/21/21 5:39 AM, Aldy Hernandez via Gcc-patches wrote:
This patch converts the remaining users of get_range_info and
get_ptr_nonnull to the range_query API.
No effort was made to move passes away from VR_ANTI_RANGE, or any other
use of deprecated methods. This was a straight up conversion to the new
API, nothing else.
A question about the uses of the RANGE_QUERY() and GLOBAL_RANGE_QUERY()
macros (hopefully functions): some clients in this patch call one or
the other based on whether cfun is set or null, while others call it
without such testing. That suggests that the former clients might
be making the assumption that cfun is null while the latter ones
make the opposite assumption that cfun is not null. It seems that
the code would be safer/more future-proof if it avoided making
these assumptions.
This is by design.
The main ambivalent user is your code in strlen/etc that can be called
from either builtin expansion or by the sprintf/strlen/etc passes, but
the common case by far is where cfun is present. We didn't want to
penalize the common case by checking.
I actually wanted the user to specifically request a global range (as
opposed to "whatever is available"). For example, in the legacy
vr-values code we want to use the global range, also rtl passes, and
perhaps gimple-pretty-print.c.
Andrew, is that your recolection as well?
Aldy
