[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