[Mlir-commits] [clang] [llvm] [mlir] [mlir] Don't assume non-erased DenseMap entries remain valid after erase. NFC (PR #199365)

[Fangrui Song]

MaskRay wrote:

> > in preparation for backward-shift DenseMap deletion which relocates surviving entries.
> 
> Is there a PR or RFC to link to here?

No RFC - a stacked of commits on top of this one

- #199369 ([DenseMap] Invalidate iterators on erase) makes `erase` call `incrementEpoch()`, an `LLVM_ENABLE_ABI_BREAKING_CHECKS`-only check. It turns stale-iterator-after-erase patterns this NFC fixes into assertion failures, so the subsequent algorithm change can land safely.
- The algorithm change that drops lazy deletion (tombstone) for TAOCP Algorithm 6.4R, relocating surviving entries to fill the hole/gap. This yields ~1% compile-time decrease https://llvm-compile-time-tracker.com/compare.php?from=f7f7cd411e63d6ce99b7dd2cfb3e74875b2ed8a3&to=53631eec76eb04ff37f17ac6105bfd719d1085a5&stat=instructions:u

Longer term this also opens the door to a metadata-based table that removes the empty key as well.
(Perhaps verstable, but not Swiss Table family implementations (absl, boost) - they are slow at small keys)

https://github.com/llvm/llvm-project/pull/199365