[PATCH] generalized range_query class for multiple contexts
Andrew MacLeod
amacleod@redhat.com
Fri Sep 25 13:17:35 GMT 2020
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.
Andrew
More information about the Gcc-patches
mailing list