manupa-arm edited a comment on pull request #23:
URL: https://github.com/apache/tvm-rfcs/pull/23#issuecomment-909254101


   Hi All,
   
   Thanks for taking the time to look at it.
   Initially, my thoughts were to use the same field for two purposes : 
   P1) Indicate candidate memories (a.k.a. pools) that each allocate be 
associated with
   P2) After the memory planner is run, it will pick one out of the list by 
reducing the candidate to exactly 1.
   
   However, having read the comments here, I feel these could be two different 
fields.
   
   >The proposed pinned memory field, however, have multiple of such 
candidates. In my understanding they can be served as aadditional hints to 
follow up passes. If the intended use is multiple candidate hints, then the tag 
is perhaps no longer approperiate because it is used to indicate one kind of 
special memory that we place the data to.
   
   For P1, I think we could use this annotation field to initially describe 
this.
   Something like (as proposed by @MichaelJKlaiberBosch 
[here](https://github.com/apache/tvm-rfcs/pull/9/files#r671371629) )  : 
   
   T1) :
   ```
   Map<String, PoolInfo> candidate_memory_pools;
   ```
   In this way, we dont need to carry this as an IRModule attribute to be 
de-referenced.
   Or should we just add a very generic 
   
   T2) :
   ```
   Map<String, Objectref> annotations;
   ```
   when the key is "candidate_memory_pools" would be the value is Map<String, 
PoolInfo> candidate_memory_pools.
   
   **I would personally prefer T1 for its direct approach here but T2 could 
also be made to work.**
   
   >What you described is closest to the "tag" field of the storage scope, 
which we put as part of the pointer and associate with most of the storage. I 
think it would be great to think in terms of this direction.
   
   > Specifically, when we have a clear distinction of memory types, "sram", 
"shared_memory", "texture". We will use the special memory tag to indicate the 
type of such kind of memory.
   
   Thereafter once the memory planner is run, it could read the annotation 
field and populate a final 'global.<memory_pool>'.
   I think this should address the all of your concerns. Let me know, if agreed 
I'll adjust the RFC text.


-- 
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: commits-unsubscr...@tvm.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to