[mlir][transform] Handle multiple library preloading passes. (#69705)

This is a new attempt at #69320.

The transform dialect stores a "library module" that the preload pass
can populate. Until n

[mlir][transform] Handle multiple library preloading passes. (#69705)

This is a new attempt at #69320.

The transform dialect stores a "library module" that the preload pass
can populate. Until now, each pass registered an additional module by
simply pushing it to a vector; however, the interpreter only used the
first of them. This commit turns the registration into "loading", i.e.,
each newly added module gets merged into the existing one. This allows
the loading to be split into several passes, and using the library in
the interpreter now takes all of them into account. While this design
avoids repeated merging every time the library is accessed, it requires
that the implementation of merging modules lives in the
TransformDialect target (since it at the dialect depend on each
other).

This resolves https://github.com/llvm/llvm-project/issues/69111.

show more ...

[mlir][Transform] Create a transform interpreter and a preloader pass (#68661)

This revision provides the ability to use an arbitrary named sequence op
as
the entry point to a transform dialect st

[mlir][Transform] Create a transform interpreter and a preloader pass (#68661)

This revision provides the ability to use an arbitrary named sequence op
as
the entry point to a transform dialect strategy.

It is also a step towards better transform dialect usage in pass
pipelines
that need to preload a transform library rather thanparse it on the fly.

The interpreter itself is significantly simpler than its testing
counterpart
by avoiding payload/debug root tags and multiple shared modules.

In the process, the NamedSequenceOp::apply function is adapted to allow
it
being an entry point.

NamedSequenceOp is **not** extended to take the PossibleTopLevelTrait at
this
time, because the implementation of the trait is specific to allowing
one
top-level dangling op with a region such as SequenceOp or
AlternativesOp.
In particular, the verifier of PossibleTopLevelTrait does not allow for
an
empty body, which is necessary to declare a NamedSequenceOp that gets
linked
in separately before application.

In the future, we should dispense with the PossibleTopLevelTrait
altogether
and always enter the interpreter with a NamedSequenceOp.

Lastly, relevant TD linking utilities are moved to
TransformInterpreterUtils
and reused from there.

show more ...