When merging a non-singleton constant range with undefined, we have to
go to overdefined. For constant ranges, we cannot guarantee that we will
be able to replace all uses of the underlying value which could lead to
contradictions with other transforms/analysis.
Note that we still cannot go to overdefined when merging undefined and a
constant range, because we initially create all elements as undefined.
But that should be fine, because that should only happen when setting
the initial concrete value.
Fixes PR44949.
Even though this might slightly pessimizes the analysis, if the
undefined value is truly not reachable, but the impact in practice seems
relatively low. I've built MultiSource, SPEC2000, SPEC2006 with -O3 +
LTO and collected the number of times CVP fired using
cat result.json | grep correlated | cut -d" " -f 10 | cut -d',' -f 1 | awk '{s+=$1} END {print s}'Without this patch: 158985
With this patch: 158957
Alternatively we could force undef constants to overdefined (as
suggested by @efriedma in D61314) or replace the undefs in the IR with
other constants.
I don't think this reasoning holds up for LVI. While we *could* replace all uses, nothing actually forces consumers of LVI to do so. And in practice, I don't believe that either JumpThreading or CVP will replace all constant lattice values. JT only looks at br/switch and CVP mostly does range-based simplifications.