[patch] convert -Wrestrict pass to ranger

Martin Sebor msebor@gmail.com
Tue Oct 6 14:51:38 GMT 2020


On 10/6/20 8:42 AM, Andrew MacLeod wrote:
> On 10/6/20 10:30 AM, Martin Sebor wrote:
>> On 10/6/20 3:45 AM, Aldy Hernandez wrote:
>>>>> -  builtin_memref dstref (dst, dstsize);
>>>>> -  builtin_memref srcref (src, srcsize);
>>>>> +  builtin_memref dstref (query, call, dst, dstsize);
>>>>> +  builtin_memref srcref (query, call, src, srcsize);
>>>>>
>>>>>     /* Create a descriptor of the access.  This may adjust both DSTREF
>>>>>        and SRCREF based on one another and the kind of the access.  */
>>>>> -  builtin_access acs (call, dstref, srcref);
>>>>> +  builtin_access acs (query, call, dstref, srcref);
>>>>
>>>> Since/if the query pointer is a member of builtin_memref which is
>>>> passed to the builtin_access ctor there should be no need to pass
>>>> a second (and third) copy to it as well.
>>>
>>> builtin_memref seems like an independent object altogether, and the 
>>> query is a private member of said object.  Are you proposing making 
>>> it public, or making builtin_access a friend of builtin_memref (eeech)?
>>
>> Either one of those seems preferable to the duplication for the time
>> being, until there's an API to access the global ranger instance.
>>
>> A better alternative, in view of your expectation of exposing
>> the instance via (cfun)->range_of_expr(), is to add some static
>> namespace scope function to access the range instance.  That
>> should make adopting the envisioned solution minimally disruptive.
>>
> The point was we don't have a fully envisioned solution yet... that is 
> just one possibility and may never come to pass.   Each pass should do 
> "the right thing" for themselves for now.

Yes, I got that.  Which is why I suggest to add a namespace scope
function to the restrict pass that can then be easily replaced with
whatever solution we ultimately end up with.

What's certain (in my mind anyway) is that storing a pointer to some
global (or per-pass) range instance as a member in each class that
needs to access it is not the solution we want long term.

Martin


More information about the Gcc-patches mailing list