merrymercy commented on a change in pull request #5962:
URL: https://github.com/apache/incubator-tvm/pull/5962#discussion_r449732736



##########
File path: python/tvm/ansor/loop_state.py
##########
@@ -0,0 +1,221 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+# pylint: disable=unused-import
+
+"""
+The definition of the "state" in search.
+
+Each LoopState corresponds to a specific schedule for its target ComputeDAG.
+A LoopState consists of: 1. a current loop structure; 2. a history of 
transformations used to
+construct the loop structure.
+The loop structure keeps a preview of how the schedule will finally look like 
after lowering the
+current state (e.g. number of iterators, the extent of each iterator, the 
compute_at locations ...).
+During the schedule search process, the loop structure can provide search 
policy with necessary
+information on how to perform further operations with the current state.
+The transform history is a sequence of TransformStep which will finally be 
mapped to schedule
+primitives. The steps can also be used for serialization of a state.
+
+The LoopState can be seen as a lightweight loop structure IR specifically for 
schedule search.
+We don't use the existing TVM IR but to extend a new structure on it is 
because:
+1. We want fast incremental change to the loop structures, search policy needs 
to get the immediate
+loop structures update rather than after TVM lowering;
+2. We want serializable transform history for replay, backtracking, and 
mutation;
+3. We may create some macro schedule primitives that represent the combination 
of several
+TVM schedule primitives.
+
+When the search is complete, we will lower the state to TVM IR with TVM's 
schedule primitives.
+Since we share a lot of common objects during search, the transformation is 
implemented in
+copy on write style. All objects are immutable, which is similar to TVM IR.
+"""

Review comment:
       ```suggestion
   The definition of the "state" in search.
   
   Each LoopState corresponds to a schedule for its ComputeDAG.
   A LoopState consists of: 1. a current loop structure; 2. a list of 
transformation steps used to
   construct the loop structure.
   The loop structure keeps a preview of how the schedule will finally look 
like after lowering the
   current state (e.g. number of iterators, the extent of each iterator, the 
compute_at locations ...).
   During the schedule search process, the loop structure can provide search 
policy with necessary
   information on how to manipulate the current state.
   The transform history is a sequence of `TransformStep` which will finally be 
mapped to TVM schedule
   primitives. The steps can also be used for the serialization of a state.
   
   The LoopState can be seen as a lightweight loop structure IR specifically 
for schedule search.
   We don't use the existing TVM IR but to extend a new structure on it is 
because:
   1. We want fast incremental change to the loop structures. The search policy 
needs to get the immediate
   loop structures update rather than after TVM lowering;
   2. We want serializable transform history for replay, backtracking, and 
mutation;
   3. We may create some macro schedule primitives that represent the 
combination of several
   TVM schedule primitives.
   
   When the search is complete, we will lower the state to TVM IR with TVM's 
schedule primitives.
   Since we share a lot of common objects during search, the transformation is 
implemented in
   copy on write style. All objects are immutable, which is similar to TVM IR.
   """
   ```
   
   
   
   Also, propagate the changes to c++ files.
   




----------------------------------------------------------------
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.

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


Reply via email to