On 9/25/20 3:17 PM, Andrew MacLeod wrote:
On 9/24/20 5:51 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
3. Conversion of sprintf/strlen pass to class.
This is a nonfunctional change to the sprintf/strlen passes. That is,
no effort was made to change the passes to multi-ranges. However,
with this patch, we are able to plug in a ranger or evrp with just a
few lines, since the range query mechanism share a common API.
Thanks for doing all this! There isn't anything I don't understand
in the sprintf changes so no questions from me (well, almost none).
Just some comments:
The current call statement is available in all functions that take
a directive argument, as dir->info.callstmt. There should be no need
to also add it as a new argument to the functions that now need it.
The change adds code along these lines in a bunch of places:
+ value_range vr;
+ if (!query->range_of_expr (vr, arg, stmt))
+ vr.set_varying (TREE_TYPE (arg));
I thought under the new Ranger APIs when a range couldn't be
determined it would be automatically set to the maximum for
the type. I like that and have been moving in that direction
with my code myself (rather than having an API fail, have it
set the max range and succeed).
Aldy will have to comment why that is there, probably an oversight The
API should return VARYING if it cant calculate a better range. The only
time the API returns a FALSE for a query is when the range is
unsupported.. ie, you ask for the range of a float statement or argument.
Right on both counts.
We could ignore the return value, or my preferred method (which I know
Andrew hates):
gcc_assert (query->range_of_expr(vr, arg, stmt));
Aldy
