Provide finer grained build targets for downstream usage of pass pipelines

[ScottTodd]

Request description

We've been using StableHLO downstream in the IREE project, specifically these Bazel targets:

        "@stablehlo//:chlo_ops",       # ChloOps in CMake
        "@stablehlo//:stablehlo_ops",  # StablehloOps in CMake

With iree-org/iree#16999, we wanted to also include VHLO to benefit from the compatibility aspects of that dialect.

We found two issues that make downstream usage tricky:

1. Depending on @stablehlo//:stablehlo_passes (StablehloPasses in CMake) pulls in a large number of dependencies, including interpreter_ops.

   • Even if we were to just depend on the API in @stablehlo//:stablehlo_portable_api, that pulls in the passes target by way of stablehlo_serialization.

2. Some parts of StableHLO have had build issues on macOS and Windows.

   • A number of these are fixed at HEAD or have open PRs to resolve them, but it's hard to take a dependency on a project that doesn't regularly test across multiple platforms and compilers as a downstream project that does

With those issues together, we found that adding a fairly small extra dependency introduced a relatively large chunk of unstable code to our build graph.

What I'd like to see as a downstream project could be a smaller footprint for the @stablehlo//:stablehlo_portable_api and @stablehlo//:stablehlo_serialization targets, perhaps by splitting the VHLO serialization passes out from @stablehlo//:stablehlo_passes. Improved support for Windows (recent MSVC compiler versions specifically) and macOS would be appreciated too.

[ScottTodd]

The specific build errors we saw on Windows were: https://gist.github.com/ScottTodd/f93a66377454bed60a16725d9039a255, and on macOS: https://github.com/iree-org/iree/actions/runs/8821674527/job/24218079731#step:6:5701. We found patches (already merged or pending) for both of those. I'm less concerned with the specific build errors and more hoping for ways to keep the upstream/downstream environment healthy.

[GleasonK]

Thanks for reporting these! A few questions:

1. What is the ideal setup of passes? Do you have a project that "does it right" and a rationale for that setup?

We have mhlo/transforms, which splits pass definitions but builds them all together. Is the ideal setup that each pass has its own header, pattern gen file, etc?

2. Regarding windows and mac CI -- we do run both upon integrating to openxla/xla (how we discovered the mac issue linked), but not in this repo. We tag every integration on GH after they have successfully integrated, so would recommend not bumping to head, but choosing a tagged release hash. For instances where we discover CI issues on integrate, we can institute a better tagging process going forward to ensure that these are included in the tagged public release, or perhaps add some CI that runs these other platforms with all LLVM bumps. That's all reasonable, we can consider this. Some of the windows macro issues didn't appear in our windows CI runs though which may leave some gaps in this workflow still.

[GleasonK]

Adding details from discussion in IREE discord:
https://discord.com/channels/689900678990135345/1085666465061019728/1242210940825374780

• Grouping all passes is not a bad thing, given the amount of boilerplate involved in setting up a pass.
• Aim to group passes by their use / function.
  • In a lower-level compiler this could be by compilation phase / device.
  • In StableHLO this is more likely "passes used by tooling/test, passes used by serialization, passes for optimization"

I think splitting off the serialization is a short-term must-do. I'd also recommend we give the probe instrumentation it's own target as well given that it's intended for use by tooling / test more than compilation or conversion.