Can plugins override built-in operators with the same name? #4686
Description
Description
I would like to confirm whether TensorRT intentionally does not support overriding built-in operators with plugins that share the same operator name. In current usage, when a built-in operator exists, registering a plugin with the same name appears to have no effect.
If this is the expected behavior, it can be limiting in practice. Users register a same-named plugin obviously indicates that the built-in implementation is insufficient—for example, due to performance issues or incomplete shape or dimension support. Blocking override removes a reasonable optimization path.
ONNX is an intermediate representation and should remain generic and extensible. Forcing users to invent non-standard operator names solely to bypass TensorRT’s built-in behavior breaks semantic clarity, reduces portability, and is conceptually awkward, since the plugin still implements the same logical operator.
Request
Please consider supporting a conflict-resolution mechanism between built-in operators and plugins, such as explicit priority, precedence rules, or versioning, so users can intentionally choose a custom plugin over the default implementation.
This would improve extensibility while preserving parser clean and ONNX graph standard.