AttrStmt was our historical way to create extensions. While it offered quite some convenience, it also created a dilemma that it may introduce new language extensions that may become incompatible with the existing semantics. e.g. an old pass may no longer be compatible with a new extension semantics.
Moving forward, we ideally would like to think about these extension points in a more structured way: - `annotations` in blocks and for loops are "hints" to the program transformations about what can be done, which means they can be safely ignored (e.g. a parallel for annotation) by most of the transformations. This enables most passes to safely ignore annotations when possible. Importantly, the object in annotations are all **constant**(so we do not need to worry about mutating its value when we change the IR). - When there are possible operations that changes the semantics of the execution block, we would like to be explicit and consider IR change that would require examination of all pass compatibility(e.g. While loop, bound of a variable which depends on other variables.) Given AttrStmt was the legacy extension point we might want to leave it was it is and deprecate(or restrict to annotations) as we continue to improve the lowering. In the meantime, we can try to leverage annotation fields for new code generation behaviors. --- [Visit Topic](https://discuss.tvm.apache.org/t/can-we-lift-tir-attrstmt-value-type-to-objectref/12118/5) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/b6c138d1d8e0fde7150ef3a58d6ddb270894647dfc8b68e05f994ba16c635c57).
