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. jeff
