Repository navigation
[Loom] Emit HAL artifacts through core target emitters - #1322
Merged
Merged
Conversation
Extend target emission artifacts with opt-in exact bundle and textual listing retention. AMDGPU and SPIR-V now copy the post-refinement bundle into artifact-owned storage only when requested, and AMDGPU transfers its assembly listing through the same core contract. Default LoomC requests allocate no storage for this metadata. This establishes core output ownership for live HAL execution without requiring target-specific tooling compilers.
Live HAL execution wrapped the core AMDGPU and SPIR-V emitters in target-specific tooling artifact providers. Replace both wrappers with one shared candidate adapter that invokes the selected device provider's core emitter using the session target environment and compiler-retained function versions. The core artifact now carries the exact target bundle, listing, and sidecars through loading and benchmark bundle production. Device providers now own only live target selection and the association with a core emitter. Collapse duplicated target-key state onto the HAL executable target, trust successful provider selection instead of revalidating compiler-owned results, and preserve the caller's diagnostic budget in the emitter request. Delete both duplicate artifact compilers and their wrapper tests, and move SPIR-V module compiler coverage beside the implementation it exercises.
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
1 participant
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.
Live AMDGPU and SPIR-V execution now uses the same core target emitters as LoomC and offline compilation. HAL tooling selects a target for the active device and invokes that emitter directly; it no longer owns a second target-specific artifact compilation layer.
The old AMDGPU wrapper repackaged the native kernel library, while the SPIR-V wrapper repeated entry selection, target compatibility analysis, bundle retention, allocation, and artifact ownership around the core module compiler. Besides living at the wrong boundary, the two implementations made live execution a separate compiler route that could drift from public emission.
Make core emitters the only artifact producers
loom_target_emit_artifact_tcan now retain the exact target bundle selected after function refinement and an optional target listing. Both products are caller-requested: ordinary LoomC emission pays no bundle-copy or listing cost, while live HAL execution requests the metadata it needs to load, report, and bundle the result after compiler scratch is released.The shared HAL candidate adapter builds one
loom_target_emit_request_tfrom the execution session, compiler-retained function versions, manifest options, diagnostic policy, and compile report. The selected device provider contributes its target profile, HAL executable row, and core emitter. AMDGPU and SPIR-V then follow the same path from prepared target-low IR to an owned core artifact.The emitter request also carries the diagnostic budget instead of letting the AMDGPU adapter silently substitute a fixed value. LoomC,
loom-check, VM testbench emission, and HAL execution all preserve the policy established by their own public or tooling boundary.Preserve live execution and bundle behavior
iree-run-loomone-shot execution,iree-test-loomscenarios, andiree-benchmark-loomcandidates now load the primary core artifact directly. Benchmark bundles still receive the target artifact, HAL executable, target listing, manifest sidecar, compile report, and exact function-refined target identity. Provider-facing names remain stable: the Vulkan device provider is still reported asspirv-vulkan-haleven though its core emitter isspirv.The target-specific tooling artifact providers and their wrapper tests are deleted. SPIR-V module compiler coverage moves beside the compiler implementation and constructs its inputs from target record bundles and function-version facts, so the test no longer reaches across the target/tooling boundary.
Reduce compile-time state and work
The SPIR-V live path no longer performs a second entry-selection and compatibility pass or creates a private block-pool owner around emission; the shared adapter uses session scratch and immediately returns it after the core emitter finishes. The AMDGPU live path removes its wrapper allocation and indirection while retaining the same native kernel-library producer.
A retained HAL candidate shrinks from 144 bytes to 96 bytes. The transient device target shrinks from 32 bytes to 16 bytes by deriving its key from the HAL executable row instead of storing a second string view and validating that both copies agree. Successful provider selection is compiler-owned state and is consumed directly rather than converted into additional internal failure paths.
Runtime dispatch, executable loading, and emitted bytes are unchanged. The change is confined to the cold compile/emission path, net-deletes production machinery, and adds no build visibility exceptions.
Ownership and coverage
Core AMDGPU and SPIR-V emitter tests cover default emission without retained metadata and requested bundle, listing, manifest, and report retention. Device-provider tests cover stable provider identity, emitter identity, target selection, and artifact format. The shared candidate test covers target-environment and function-version propagation, optional listing flags, diagnostic limits, report preservation, and artifact teardown. End-to-end AMDGPU and Vulkan scenario execution exercises the resulting artifacts through the production HAL loader.
Reviewer Notes
The first commit adds opt-in metadata retention to core emitter artifacts. The second switches HAL execution to those artifacts, simplifies device-target state, moves SPIR-V compiler coverage to its owner, and deletes both target-specific tooling compilers.
The highest-value review surfaces are
loom/target/provider.h, the AMDGPU and SPIR-V emitter retention paths, andloom/tooling/execution/hal/candidate.c. The central invariant is that tooling selects and stitches capabilities, while core target emitters alone interpret prepared compiler state and construct artifacts.