On 08/03/2017 02:45 AM, Richard Biener wrote:
> Well, simply because the way as implemented isn't a must-alias query
> but maybe one that's good enough for warnings (reduces false positives
> but surely doesn't eliminate them).
OK.  So it's more about building a proper must-alias query and less
about exploiting the alias oracle to give us more precise information.
That was the source of my confusion.

> There's a must alias query already, in stmt_kills_ref_p.  It's a matter
> of refactoring to make a refs_must_alias_p.
Funny you should mention that -- stmt_kills_ref_p is what I had in mind
when Martin first posted this work.  DSE essentially raises a must-alias
query via that interface and I'd fully support refactoring
stmt_kills_ref_p so that it would be used for DSE as well as Martin's work.

> Then propose that "overlap range" stuff separately.
That works for me.

> But I'm against lumping this all in as an innocent change suggesting
> the machinery can do sth (must alias) when it really can't.  I also
> do not like adding a "must alias" bool to the may-alias APIs as
> the implementation is fundamentally may-alias, must-alias really
> is very different.
That works for me.

> And to repeat, no, I do not want a "good-enough-for-warnings" must-alias
> in an API that's supposed to be used by optimizations where "good enough"
> is not good enough.
Understood and agreed.

I'll note that I suspect Martin's desire to reduce false positives and
potentially weaken things here is driven by the pushback he's had on
implementing warnings with a "too high" false positive rate in the past.


Reply via email to