Cross-compile target modules and dispatch to executor by mehrdad2m · Pull Request #3033 · PennyLaneAI/catalyst

mehrdad2m · 2026-07-16T18:21:39Z

Context:
This PR adds a compile path that turns a catalyst.target-tagged QNode into a standalone object and either statically links it (local) or ships it to a remote executor.

Description of the Change:

Adds cross-compile-targets pass which lowers each catalyst.target nested module and emits a standalone .o. Then it records the path as catalyst.object_file, and reduce the module to external declarations. Local targets are also recorded for static linking.
Adds dispatch-executor-targets pass which ships the remote binaries and rewrites their host calls into executor.launch.
Modifies the compiler driver to run both passes after the bufferization stage and writes the local objects to a .objects manifest for the linker.

Benefits:

Possible Drawbacks:

Related GitHub Issues:

Assisted by: Claude code

github-actions · 2026-07-21T13:48:39Z

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md on your branch with:

A one-to-two sentence description of the change. You may include a small working example for new features.
A link back to this PR.
Your name (or GitHub username) in the contributors section.

maliasadi

Thanks @mehrdad2m! Will you fix the build issues on this PR or on the base branch/PR?

maliasadi · 2026-07-21T21:18:12Z

+		-DLLVM_TARGETS_TO_BUILD="${LLVM_TARGETS_TO_BUILD}" \
 		-DLLVM_ENABLE_PROJECTS="$(LLVM_PROJECTS)" \
 		-DLLVM_ENABLE_ASSERTIONS=ON \


this is consistent with other places:

Suggested change

-DLLVM_TARGETS_TO_BUILD="${LLVM_TARGETS_TO_BUILD}" \

-DLLVM_ENABLE_PROJECTS="$(LLVM_PROJECTS)" \

-DLLVM_ENABLE_ASSERTIONS=ON \

-DLLVM_TARGETS_TO_BUILD=${LLVM_TARGETS_TO_BUILD} \

-DLLVM_ENABLE_PROJECTS=$(LLVM_PROJECTS) \

-DLLVM_ENABLE_ASSERTIONS=ON \

This was added to allow multiple targets/project to be parsed correctly. e.g. without the quotation, cmake can not parse DLLVM_TARGETS_TO_BUILD=X86;AArch64 correctly. Let me know if you know a cleaner way to achieve this.

maliasadi · 2026-07-21T21:21:12Z

+// CHECK: executor.send_binary("ADDR:PORT", "/tmp/target_compute.o")
+// CHECK-NOT: executor.send_binary


What do CHECK and CHECK-NOT executor.send_binary check?

This was added to ensure we only send the binary once even if we have multiple launch_kernels on the same object file. I'll add a comment to clarify that

maliasadi · 2026-07-21T21:57:00Z

+
+        1. Injects `executor.open` into `setup()` (once per unique address) and `executor.send_binary`
+           into `setup()` (once per module).
+        2. Replaces every host-side `func.call` to the module's entry functions with a


What's the strategy to replace host func.call with executor.launch? What does filter the host-side func.calls which need to run on the host from those need to be handled with executor?

Ah good catch. This docstring is outdated. I updated it in 2aafda2. the func.calls are unaffected by this pass. It only acts on nested modules with catalyst.dispatch attribute.

maliasadi · 2026-07-22T15:25:59Z

+
+    // Open a session (once per address), ship the object recorded in
+    // `catalyst.object_file`, and rewrite each host-side func.call into a `executor.launch`.
+    LogicalResult dispatchViaOrcExecutor(ModuleOp host, ModuleOp nested,


What does this function do? 🤔

It handles one dispatch module which involves opening the session, shipping the object, and rewriting that module's launch_kernels into executor.launch. I just noticed though that the name carries an implementation detail it shouldn't, I renamed it to dispatchTargetModule. 350665b

maliasadi · 2026-07-22T15:33:35Z

+            dumpLLVMIR(*llvmModule, kernelDir, name.str() + ".ll");
+        }
+        std::string objPath =
+            emitObjectFile(std::move(llvmModule), name, kernelDir, *targetMachine);


Could you add a guard before the compile loop to fix the object-file name collision issue? as it generates {workspace}/{name}/{name}.o and for two targets with the same sym name, this will silently fail.

Good catch! Although having two targets with the same sym name would not be a valid IR to begin with, we default to "unnamed" for modules with no name and that could trigger this issue. I added a guard e22b237

maliasadi · 2026-07-22T15:36:27Z

    let summary = "Apply the passes scheduled with the transform dialect.";
 }

+def CrossCompileTargetsPass : Pass<"cross-compile-targets", "mlir::ModuleOp"> {


Co-authored-by: Ali Asadi <10773383+maliasadi@users.noreply.github.com>

mehrdad2m added 2 commits July 16, 2026 14:11

Add cross-compile and dispatch passes.

5d9d458

Assisted by: Claude code

support multi target parsing in makefiel

0d60f8a

mehrdad2m added the backline label Jul 17, 2026

mehrdad2m requested a review from maliasadi July 21, 2026 13:48

mehrdad2m mentioned this pull request Jul 21, 2026

Support skipping inlining annotated nested modules #2838

Merged

Merge branch 'isolate-remote-kernels' into cross-compile-targets

9b4c5c9

maliasadi reviewed Jul 22, 2026

View reviewed changes

mehrdad2m and others added 11 commits July 22, 2026 12:09

Apply suggestions from code review

5e7d217

Co-authored-by: Ali Asadi <10773383+maliasadi@users.noreply.github.com>

Apply suggestions from code review

2e2f29e

Co-authored-by: Ali Asadi <10773383+maliasadi@users.noreply.github.com>

Apply suggestion from @maliasadi

07f765c

Co-authored-by: Ali Asadi <10773383+maliasadi@users.noreply.github.com>

reject duplicate target names to be compiled

e22b237

Update mlir/lib/Driver/CompilerDriver.cpp

4218b4e

Co-authored-by: Ali Asadi <10773383+maliasadi@users.noreply.github.com>

add comment

948d5d3

update docstring

2aafda2

update dispatch target func name and update comments

350665b

quote the workspace

ebbdb5c

format

7838e13

format

c9c4eae

mehrdad2m requested a review from maliasadi July 22, 2026 20:04

		// CHECK: executor.send_binary("ADDR:PORT", "/tmp/target_compute.o")
		// CHECK-NOT: executor.send_binary

Uh oh!

Conversation

mehrdad2m commented Jul 16, 2026

Uh oh!

github-actions Bot commented Jul 21, 2026

Uh oh!

maliasadi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants