[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