[Mlir-commits] [mlir] [MLIR][NFC] Retire let constructor for Bufferization (PR #129850)
Mehdi Amini
llvmlistbot at llvm.org
Wed Mar 19 03:03:12 PDT 2025
================
@@ -63,11 +63,9 @@ parseHeuristicOption(const std::string &s) {
}
struct OneShotBufferizePass
- : public bufferization::impl::OneShotBufferizeBase<OneShotBufferizePass> {
- OneShotBufferizePass() = default;
-
- explicit OneShotBufferizePass(const OneShotBufferizationOptions &options)
----------------
joker-eph wrote:
> , but it may quickly become prohibitively expensive when later commits change surrounding lines of code causing merge problems or change/remove the dependencies of the locally modified code.
Right: but you're trading off the cost of your own migration and maintenance with cost of the upstream maintenance by doing so.
Not saying it's not possible to deprecate things upstream, we often do it, but it's not straightforward in general and definitely not free. Especially for cleanups like this (which are overdue by O(years) by the way), adding more maintenance cost on upstream is taking a toll on the few people who are actually doing cleanup/maintenance/tech debt pay up. So if I have to choose, I definitely will pass the cost onto you maintaining this patch and paying the price of possible merge conflicts downstream (these merge conflicts are actually a good reminder of paying the tech debt, and provide a motivation for folks to finish their migration downstream, or decide for themselves if the cost of the on-going debt is worth it to delay the migration).
https://github.com/llvm/llvm-project/pull/129850
More information about the Mlir-commits
mailing list