Constants in MLIR are not globally unique, unlike in LLVM IR. Therefore, reusing previously-translated constants might create operations that are not dominated by the constant (because the previously-translated ones can be placed anywhere)
This indeed misses some opportunities where we actually can reuse a previously-translated constant, but verbosity is not our first priority here.
(Note that the test case attached looks really similar to that in D124402, but the indices in ConstantExpr-GEP are different: in this patch all of them are zeros. Without this patch, the llvm.getelementptr translated from the second ConstantExpr-GEP will try to use llvm.constant(0: i32)-s that are below itself, because we're reusing the cached ConstantInt-type zero value translated earlier)
Could you please describe in text what was happening before this patch? This will help to differentiate regressions from other kinds of test breakages in the future.