https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125986
--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Aldy Hernandez from comment #2) > > And the reason we have this killing def, is that _155 is set as an > equivalence along the path, because it is a PHI. > > <bb 57> [local count: 1015094502]: > # ip_155 = PHI <prephitmp_374(52), ip_210(56), ip_210(55)> > > Remember the path is 52->57, so ip_155 is _374, which kills the def along > the path, thus causing the query() to avoid looking at the root oracle. > Also, the statement which has the relation we are trying to resolve is: Well is this or is it not a killing def? if this is a path and we effectively have ip_155 = prephitmp_374, we absolutely get an equivalence, but we should notregister a killing def? its a copy which does not kill the def or the RHS? Isn't just adding it to the equivalence set enough? Or am I brain farting? its been a while since I thought about this :-) It seems the killing def is the problem... otherwise it seems the relation oracle would already doing the right thing and query the root oracle. I dont see what the last patch would accomplish, it queries the oracle but doesn't do anything with the relation. The fur_source that the path ranger is using should automatically query the root ranger if the def wasn't killed. the other option is maybe we also need the fur_source relation query to do a follow-up query if the first one returns nothing... Do a specific query between just the 2 specific operands on the statement leading into the path. I am not 100% sure if that 100% safe... I have to think about it in the presence of an equivalence killing def... but its something for you to play with. it seems to pass the DOM assert anyway.
