Rename CompiledKernel to CompiledModule#4322
Merged
Merged
Conversation
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Renaud-K
approved these changes
Apr 14, 2026
Collaborator
Renaud-K
left a comment
Renaud-K
left a comment
There was a problem hiding this comment.
Looks good. Thank you.
github-merge-queue
Bot
removed this pull request from the merge queue due to a conflict with the base branch
lmondada
force-pushed
the
lm/rename-compiled-kernel
branch
from
c7ef0cf to
e91881c
Compare
Signed-off-by: Luca Mondada <luca@mondada.net>
lmondada
force-pushed
the
lm/rename-compiled-kernel
branch
from
e91881c to
0b0b33a
Compare
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
mitchdz
pushed a commit
to mitchdz/cuda-quantum
that referenced
this pull request
Apr 15, 2026
This is a first follow-up from yesterday's conversation. It renames `CompiledKernel` to `CompiledModule`. This is to clarify the exact scope of this type: > A `CompiledModule` is the collection of artifacts produced by CUDAQ when compiling a Quake MLIR module. This is slightly different from a "compiled kernel", as it may contain zero, one or multiple entrypoints, depending on what was in the module and how it is compiled. I'm working separately on another PR that will make a clearer distinction between the CompiledModule and its artifacts (e.g. `JitArtifact` come with an entrypoint, whereas `MlirArtifact`s do not). It will also move the logic on how to "execute" `CompiledModule`s out of the type itself. Signed-off-by: Luca Mondada <luca@mondada.net>
AsherBond
pushed a commit
to ElasticProvisioner/cuda-quantum
that referenced
this pull request
Apr 22, 2026
This is the second follow up after NVIDIA#4322 from our discussion last week. This PR 'dumbs down' the `CompiledModule` type in the following sense - it does not make any assumptions anymore on what the compilation artifacts contain (e.g. before `JitArtifact` kept track of the various named entrypoints according to some naming convention) - it does not know what 'executing' a `CompiledModule` means The result is a pretty clean 'container' type that just knows how to store artifacts of different kinds. The only methods that still rely on some naming conventions are `getArgsCreator` and `getReturnOffset`, which exist purely for convenience (can be removed if you wish). This logic (which is dependent on conventions), now lives outside of the type. The naming conventions and entrypoint resolution was fully moved to construction (in `runtime/internal/compiler/include/cudaq_internal/compiler/CompiledModuleHelper.h`). The execution logic on the other hand was moved to the only placed it is currently used in (`runtime/cudaq/platform/qpu.cpp`). We might need to move this further as we unify kernel execution for C++ and Python, but wasn't sure where it would eventually land (and in what form). Signed-off-by: Luca Mondada <luca@mondada.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a first follow-up from yesterday's conversation. It renames
CompiledKerneltoCompiledModule. This is to clarify the exact scope of this type:This is slightly different from a "compiled kernel", as it may contain zero, one or multiple entrypoints, depending on what was in the module and how it is compiled.
I'm working separately on another PR that will make a clearer distinction between the CompiledModule and its artifacts (e.g.
JitArtifactcome with an entrypoint, whereasMlirArtifacts do not). It will also move the logic on how to "execute"CompiledModules out of the type itself.