See
https://google.github.io/xls/adding_ir_operation/ and let us know if that's what you were looking for -- note we do not currently have a way to introduce arbitrary nodes in a /runtime pluggable/ way (similar to how we had a CustomCall operations in XLA, if by some chance you happen to be familiar with that), all operators are statically known, so you would need to fork/modify, as I imagine you're already intending to do in order to add the pass. Having runtime extension in a limited form that the compiler can still understand as a black-box operation (i.e. that would not be subject to internal optimizations) is part of the "FFI" (foreign function interface) work that is starting this quarter, which intends to let you instantiate external verilog modules directly into XLS designs and schedule them in pipeline generation -- you can see other threads in the xls-dev google group on the thinking / plan around how FFI would work, e.g.
https://groups.google.com/g/xls-dev/c/SQJuX9yI1W0/m/QwUCiYj0BwAJ . If you're thinking this would be a new operation that you'd want to contribute to upstream XLS (vs keeping in an experimental fork) we should probably discuss. Note that we tend to be a little conservative about introducing new operators because in general introducing arbitrary nodes into a compiler suffers from the expression problem:
https://en.wikipedia.org/wiki/Expression_problem due extension both in representation (fundamental IR node operations) and behaviors (passes that manipulate and reason about the IR nodes and associated costs), so keeping compiler internal surface area well known and understood has many benefits for the reasoning and evolution of a compiler, which is why we tend to extend the set judiciously, and only when there's not other more "desguaring the new operation to the existing set" oriented options available.
Cheers,
- Chris Leary