Skip to content

Support Backend Specific Node Verifiers #3450

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nickgg opened this issue Aug 22, 2019 · 1 comment
Closed

Support Backend Specific Node Verifiers #3450

nickgg opened this issue Aug 22, 2019 · 1 comment
Assignees

Comments

@nickgg
Copy link
Contributor

nickgg commented Aug 22, 2019

Currently Node Verification is Backend independent, but there are components of the Node that depend on the backend for validity. Some examples:

  • Different backends have different dimensional limits for various Nodes (e.g. CPU/Interp is limited to 6 dimensions for BatchedReduceAdd, but OCL is limited to 4).
  • Tensor Alignment will be phased in to some backends before others.
  • Fused Activations are supported on specific backends only (initially just Habana).
  • OpenCL has a limitation on the group parameter for Convolutions which doesn't exist on other backends.

The way we handle this currently is to put asserts in the backend specific code when executing these instructions, but this is brittle and spread through various places in the code. We should be able to tell if a Function is valid at compile time.

To fix this, we could add a Verify() method to Backend which can be overriden to handle these backend specific checks - similar to how transformPostLowering works now.

@shajrawi
Copy link
Contributor

This is related to #3452 : I am currently working on layout verifier, the natural place for it Function::verify(), but the layout requirements are backend dependent of course. To make a clean implementation of that larger issue, we would need to support this by either: having backend-agonistic checks, that can be extended in a specific backend or requirement methods that can be overridden by specific backends.
The downside of the second approach is that the optimizer (for example) might make certain assumptions that verify as correct in the base method but break a target backend that overwrote said method.

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 a pull request may close this issue.

2 participants