[CIR][MERGE-SPLIT-COMPILATION] Adds a compilation step that merges Device and Host CIR into a single module and can co-optimize their execution

[koparasy]

This PR is a draft / working skeleton that documents my current progress on CIR host–device combine. The goal here is not to land this as-is, but to outline the individual components that need to change to enable the desired functionality.

Once I have an end-to-end pipeline working for PolyBench on AMD, I plan to split this into smaller, focused, reviewable PRs. Until then, this PR serves as a reference point for understanding the overall direction and moving pieces.

Current status

• Introduce a new cc1 Action that reads two CIR inputs (host + device) and merges them under a single module.
• Fix existing Actions to correctly operate on CIR bytecode instead of textual CIR
  • ⚠️ There is a known memory leak here that still needs to be addressed.
• Fix parsing of selected CIR attributes:
  - GPUBinaryHandle
  - ConstDataArrays
• Add HIP ABI support (tracked separately as PR [CIR][HIP] Add ABI support for HIP #2087).
• Allow the driver to emit .cir files and make the driver aware of CIR lowering.
• This introduces a new driver flags that genrate an Action of TY_CIR type that is intentionally non-mergeable with earlier Actions.
  - This separation is required so we can hook the follow-up Action that consumes both host and device CIR.

Next steps

• Make the Driver dependency resolution work properly and call the individual tools properly.
• Generate the respective tool. Do we want the tool to be a separate CC1 command or an individual tool.
• Extend the tool to allow splitting of the CIR file. Every command needs to emit a single file to follow Driver semantics. Currently the implementation splits and emits both Host and Device.
• Build PolyBench to verify that this is working on something more realistic.

[koparasy]

@RiverDave and @bcardosolopes I will keep this PR open so that both of you can have an idea of the progress.

[koparasy]

Currently the clang driver action graph looks like this:

                     +- 0: input, "vecadd.cu", hip, (host-hip)
                  +- 1: preprocessor, {0}, hip-cpp-output, (host-hip)
               +- 2: compiler, {1}, cir, (host-hip)
               |     +- 3: input, "vecadd.cu", hip
               |  +- 4: preprocessor, {3}, hip-cpp-output
               |- 5: compiler, {4}, cir
            +- 6: comebinecir, {2, 5}, cir
         +- 7: splitcir, {6}, cir, (host-hip)
         |              +- 8: splitcir, {6}, cir
         |           +- 9: backend, {8}, assembler, (device-hip, gfx942)
         |        +- 10: assembler, {9}, object, (device-hip, gfx942)
         |     +- 11: linker, {10}, image, (device-hip, gfx942)
         |  +- 12: offload, "device-hip (amdgcn-amd-amdhsa:gfx942)" {11}, image
         |- 13: linker, {12}, hip-fatbin, (device-hip)
      +- 14: offload, "host-hip (x86_64-unknown-linux-gnu)" {7}, "device-hip (amdgcn-amd-amdhsa)" {13}, cir
   +- 15: backend, {14}, assembler, (host-hip)
+- 16: assembler, {15}, object, (host-hip)
17: linker, {16}, image, (host-hip)

We are losing information regarding the device arch.

[bcardosolopes]

I was originally thinking about something like:

module {
  cir.host {
     ...
  }

  cir.device {
    ...
  }
}

Any reason why you need the cir.offload.container wrapping both of them?
Based on our experience with optimizing cross library with LLVM IR dialect, we had to flatten the namespace and put everything in the same module (while adding an extra attribute to indicate the symbol origin, such that we can split them back after optimizations). In our case lots of problems came from symbol definitions being only available within another cir.library and MLIR not being able to properly handle symbol tables across them, is this a problem for this approach?

[bcardosolopes]

CIRCombineJobClass -> CIRCombineHostDeviceJobClass