On 10/6/20 4:51 PM, Martin Sebor wrote:
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.
Tell you what. I'll make your class public, access it's internal
members as you describe (ughh), and you can do anything else post-commit.
Aldy
