Skip to content

Conversation

@AndreyPavlenko
Copy link
Contributor

@AndreyPavlenko AndreyPavlenko commented Oct 16, 2025

The purpose of this refactoring is to simplify development for new architectures by subclassing the base class instead of adding conditional code blocks.

The main changes:

  • Allow metaclasses injection: use XPUBackendMeta from the .meta submodule as the metaclass, if it exists.
  • Try to find an arch-specific implementation in the .arch.<name> submodule.
  • Create the list of passes in separate methods to allow subclasses to modify it.

@etiotto etiotto changed the title XPUBackend refactoring to facilitate arch-specific implementations [NFI]: XPUBackend refactoring to facilitate arch-specific implementations Oct 16, 2025
Copy link
Contributor

@etiotto etiotto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering whether we should use easier to understand alternative. Have you considered:

  1. Inheritance: create a base class that can be derived (my preference)
  2. class Decorators to modify the behavior of the BE after creation

@AndreyPavlenko
Copy link
Contributor Author

  1. Inheritance: create a base class that can be derived (my preference)

XPUBackend is the base class. Arch-specific implementations derive from it and override the required methods. For example, they could override get_llir_passes() and add/remove passes.

  1. class Decorators to modify the behavior of the BE after creation

It could be done, by defining a metaclass, but the inheritance should be used in most use-cases.

 - Allow metaclasses injection: use XPUBackendMeta from the .meta submodule as the metaclass, if it exists.
 - Try to find an arch-specific implementation in the .arch.<name> submodule.
 - Create the list of passes in separate methods to allow subclasses to modify it.
@AndreyPavlenko AndreyPavlenko force-pushed the AndreyPavlenko/backend-refactor branch from 2c0c89d to 055acd2 Compare October 21, 2025 08:50
return pm

@classmethod
def get_ttir_passes(cls, opt):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we separate the changes about get_*ir_passes in another PR? I am not sure I like it, but the other changes don't need to be blocked by it.

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.

3 participants