# \[pre-RFC\] Additional Target Hooks **URL:** \ **Category:** RFC\ **Created:** [July 8, 2021, 3:38pm UTC](https://discuss.tvm.apache.org/t/pre-rfc-additional-target-hooks/10430 "2021-07-08T15:38:20Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![areusch](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/areusch/32/2118_2.png) [@areusch](https://discuss.tvm.apache.org/u/areusch)\ **Post date:** [August 7, 2021, 12:55am UTC](https://discuss.tvm.apache.org/t/pre-rfc-additional-target-hooks/10430/4 "2021-08-07T00:55:36Z")
@Mousius thanks for this RFC and apologies for the long delay. I read this in conjunction with [[RFC] Arm® Ethos™-U Integration](https://discuss.tvm.apache.org/t/rfc-arm-ethos-u-integration/10504) to try to understand the initial application. I think that should be a sufficient example, but let me know if there are other use cases I should consider. I discussed this with @jroesch and mbs-octoml at length a couple days ago. Documenting our discussion here. Overall: - We agree there should be a way to leverage external codegen without recreating the entire compilation pipeline. - We want to ensure that this work is compatible with the ongoing TEcompiler refactor work–specifically, the TE-compiler refactor is now going to move towards unifying Relay → TIR lowering (and later unifying lower down the pipeline) across the Graph, AOT, and VM executors. - To that end, the case for a `relay_to_tir` hook and a `tir_to_runtime` hook seems clear. We’d like to clarify the interface of this hook, and propose: - For the `tir_to_runtime` hook, we presume this will follow the existing `relay.ext.` interface, just it will be specific to the target rather than a compiler attribute marked onto the relay Function. - In terms of user interface: theoretically it should be possible to hand TVM an unannotated Relay function plus a Target which specifies the available CPUs/accelerators, and TVM should leverage its knowledge of schedules to assign functions to devices. Currently, we either specify a mostly-homogenous target or manually mark functions to be run externally. In the future, we’re pondering that the interface could be: either TVM will assign the each function call to a target; or you can override this and mark it manually using a per-call-site or per-function attribute. In this case, the target contained in that attribute is not a composite Target, but instead a shorthand descriptor for one of the pieces of the overall Target. For example, Target could be specified as `low_power_cpu: c -mcpu=cortex-m0; inference_cpu: c -mcpu=cortex-m7f`, and call sites could be assigned to either `low_power_cpu` or `inference_cpu`. Does this sketch of a direction align with how you’d like to enable these target hooks? --- _[View the full topic](https://discuss.tvm.apache.org/t/pre-rfc-additional-target-hooks/10430)._