Skip to content

Add Mapping analysis to support IR mapping. - #39

Draft
KFAFSP wants to merge 3 commits into
torch-spyre:mainfrom
KFAFSP:kfaf/mapping
Draft

Add Mapping analysis to support IR mapping. #39
KFAFSP wants to merge 3 commits into
torch-spyre:mainfrom
KFAFSP:kfaf/mapping

Conversation

@KFAFSP

@KFAFSP KFAFSP commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

This PR adds the Mapping helper that is used downstream to query and manipulate the mapping of mappable operations to architecture graph resources.

It also adds the light weight DefaultDevice analysis which streamlines downstream users and is built on the mapping annotations.

Changing the ID of a resource is now a blocking operation. Additionally,
calling `getOrAssign` will block before the test, meaning that it will
never override the IDs of resources.

Signed-off-by: Karl F. A. Friebel <karl.friebel@ibm.com>
@KFAFSP
KFAFSP force-pushed the kfaf/mapping branch 2 times, most recently from 24879f9 to 694bd51 Compare September 10, 2026 13:05
This new class provides a way of querying and updating the mappings of
operations to architecture graph resources. It hard-codes the
requirement that our programs may only refer to one device at a time.

This needed some minor improvements to existing infrastructure:
- Added some helpers to `MapsToAttr` to declare intent.
- Changed the `DeviceOp` verifier such that the device name is not a
  legal Resource ID.
- Changed interface of `ResourceIds` and `ResourceKinds` with built-in
  casting feature.

Signed-off-by: Karl F. A. Friebel <karl.friebel@ibm.com>
This class provides a box-standard MLIR analysis that can be used to
obtain a `ktdf_arch` Device based on the mapping of the current op. It
unifies the downstream handling of obtaining the device, as well as
error messaging, and canonicalizes the `DeviceRef` as the safest way
for derived analyses to reference the device.

Signed-off-by: Karl F. A. Friebel <karl.friebel@ibm.com>
@KFAFSP

KFAFSP commented Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

This is needed for torch-spyre/dataflow-scheduler#148 and is lacking test coverage of the new features (since they are quite straight-forward and based on ones with existing coverage).

@KFAFSP
KFAFSP marked this pull request as draft September 10, 2026 16:04
@KFAFSP

KFAFSP commented Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

After some discussion, a better design is needed:

  • mapping should allow sets of resources
  • MappableOpInterface could allow customization and strong type safety
    • this could also allow ktdf.stage to keep applicable_units as its mapping constraint!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant