junrushao1994 commented on a change in pull request #22:
URL: https://github.com/apache/tvm-rfcs/pull/22#discussion_r704751471



##########
File path: rfcs/0022-tir-non-scalar-constants.md
##########
@@ -0,0 +1,107 @@
+
+- Feature Name: tir_non_scalar_constants
+- Start Date: 2021-06-01
+- RFC PR: https://github.com/apache/tvm-rfcs/pull/22
+- GitHub Issue: TBD
+
+# 1. Summary
+
+This RFC proposes how non-scalar constants could be represented in TIR and 
used by passes in the lowering process.
+
+# 2. Motivation 
+
+Currently, the non-scalar constants could be represented in Relay 
(relay.Constant) to be used by relay passes but not in TIR. Therefore, when 
performing lowering using TIR passes, we have to maintain a side-channel of 
tir::Var to constant non-scalar data mapping to perform transformations that 
could use the knowledge where some of the data are constants.
+
+Few example scenarios as further motivation :
+
+## Weight compression
+
+When lowering for accelerators (E.g. : [Arm(R) Ethos(TM)-U 
NPU](https://github.com/apache/tvm-rfcs/pull/11)), certain operations will need 
to get tiled to co-optimize performance and memory utilization. Such tiling 
patterns create slices of weights that need compressing that will end up with 
varying sizes. Therefore, the knowledge of some tir::Vars refer to constants 
are critical in the level of TIR to perform this.
+
+## Memory Planning
+
+The TIR program has the ability to express both inter and intra operator 
memory requirement, post-scheduling as explained further by [Unified Static 
Memory Planning RFC](https://github.com/apache/tvm-rfcs/pull/9). It would be 
better if the constants could be embedded to the TIR PrimFunc. Moreover, this 
allows various [target-dependent 
lowerings](https://github.com/apache/tvm-rfcs/pull/10), to produce TIR 
PrimFuncs with constants in it.

Review comment:
       Oh I am not thinking of hiding the content of constant Tensors, but of 
putting them anywhere else, e.g. IRModule's attributes, to mimic the behavior 
where we put those data in `.rodata` section of an artifact.
   
   In benefit of doing this is that it is more consistent with our unified IR 
approach and this mechanism could be shared between Relay and TIR.
   
   Let me know what you think :-)
   




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to