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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/23#issuecomment-909254101
