https://gcc.gnu.org/g:e1eb2472c965a1d1f16e157da3cbf8c439551646
commit r16-7957-ge1eb2472c965a1d1f16e157da3cbf8c439551646 Author: Martin Jambor <[email protected]> Date: Mon Mar 9 12:45:26 2026 +0100 ipa-cp: Allow more precise contexts in the verifier (PR124291) Similarly to PR123629, the issue again stems from that when propagating polymorphic contexts, when there are no known "values" in the corresponding lattice of the caller we use just the information on the edge and when there are some we combine them with the information, and from the fact that we iterate the propagation in strongly connected components of the call graph (SCCs). In the first iteration over such SCC, we process the edge from unmark/1097720 to onChild/1097719 before we determined the lattices of the caller. In the second iteration, we already know what context there will be in the first unmarks's parameter and so can add a more precise value to the corresponding lattice of onChild. Because we always add values to the lattices and never "improve" them, we get two values for the call. In PR123629, that actually described reality well because the caller's lattice had the variable flag set, without cloning the caller we could not assume we could use the caller's lattice value and so both values were possible (and in fact both cases happened, the problem was that their meet failed). In this case however, one could argue that the lattices contain wrong info or at least information that is misleading because the caller's lattice contains just that single "constant" and the variable flag is not set. We know that regardless of cloning decisions for the caller the more precise derived value will be the case. And indeed since I changed the cloning code to re-gather all constants for the given set of callers, that code arrives at the more precise context. For the record they only differ in the fact that the more precise one has the dynamic flag cleared. I have thought about how to fix up the lattices in one way or another but so far it has always turned ugly. Therefore this patch simply changes the verification to simply allow this situation because even though the final result is just a bit more precise than what was expected, it is however correct. There will not be any attempt to clone for the more precise context because all the call graph edges will have been redirected away. The only "issue" is that the less precise contexts take up place in the lattice, which has a limited length. That should not be a problem in practice. gcc/ChangeLog: 2026-03-06 Martin Jambor <[email protected]> PR ipa/124291 * ipa-cp.cc (ipcp_val_replacement_ok_p): Allow more precise contexts that what the clone was originally intended for. Diff: --- gcc/ipa-cp.cc | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc index b4e01a92344e..4765ef972b9d 100644 --- a/gcc/ipa-cp.cc +++ b/gcc/ipa-cp.cc @@ -5920,11 +5920,19 @@ ipcp_val_replacement_ok_p (vec<tree> &, int index, HOST_WIDE_INT offset, ipa_polymorphic_call_context value) { - if (offset != -1) + if (offset != -1 + || known_contexts.length () <= (unsigned) index + || known_contexts[index].useless_p ()) return false; - return (known_contexts.length () > (unsigned) index - && !known_contexts[index].useless_p () - && known_contexts[index].equal_to (value)); + + if (known_contexts[index].equal_to (value)) + return true; + + /* In some corner cases, the final gathering of contexts can figure out that + the available context is actually more precise than what we wanted to + clone for. Allow it. */ + value.combine_with (known_contexts[index]); + return known_contexts[index].equal_to (value); } /* Decide whether to create a special version of NODE for value VAL of
