zxybazh opened a new pull request, #13084:
URL: https://github.com/apache/tvm/pull/13084

   The current datatype issue #12997 could cause the postproc application to 
fail in massive number, causing tons of exception logging onto the screen via 
`LOG(WARN)`. This change removes the postproc application exception logging in 
the utility of search strategy, the reasons are:
   1. The errors are triggered in multi-thread environment, the logging is hard 
to read anyway
   2. We have a large population of candidates to mutate and apply postproc, in 
scenarios like the data type issue, it generates tons of logging, which is not 
helpful.
   3. To debug we always need to run the postproc alone, which doesn’t matter 
in this case.
   4. Without the warning log, we can still see failed postproc number count in 
the logging, and check for failure if necessary. If all the application fails, 
we would be able to see the workload fails in the performance tuning table. 
Example:
   ```c++
   2022-10-13 17:03:42.383 INFO 
/home/apache/tvm/src/meta_schedule/search_strategy/evolutionary_search.cc:595 
Evolve iter # 3 done. Summary:
   Postproc # 0 [meta_schedule.DisallowDynamicLoop(0x561b625b8238)]: 0 
failure(s)
   Postproc # 1 [meta_schedule.RewriteParallelVectorizeUnroll(0x561b62606e78)]: 
589 failure(s)
   Postproc # 2 [meta_schedule.RewriteReductionBlock(0x561b6266a358)]: 0 
failure(s)
   Postproc # 3 [meta_schedule.RewriteLayout(0x561b625323b8)]: 0 failure(s)
   ```
   There’s another alternate way I thought about to do this, which is to add a 
field called `postproc exception` counter that can output after the output of 
failures like
   ```c++
   2022-10-13 17:03:42.383 INFO 
/home/apache/tvm/src/meta_schedule/search_strategy/evolutionary_search.cc:595 
Evolve iter # 3 done. Summary:
   Postproc # 0 [meta_schedule.DisallowDynamicLoop(0x561b625b8238)]: 0 
failure(s)
   Postproc #1 [meta_schedule.RewriteParallelVectorizeUnroll(0x561b62606e78)]: 
0 failure(s) 589 exceptions(s)
   Postproc # 2 [meta_schedule.RewriteReductionBlock(0x561b6266a358)]: 0 
failure(s)
   Postproc # 3 [meta_schedule.RewriteLayout(0x561b625323b8)]: 0 failure(s)
   ```
   I think this is unnecessary given we can always check failure reasons here 
and we would always expect postproc to work except verification postprocs.
   
   There's only one other logging interface like this in Postproc 
implementation 
[here](https://github.com/apache/tvm/blob/605876e638a7303acb63ef8a9dd9ebfefc30ae24/src/meta_schedule/postproc/rewrite_tensorize.cc#L46)
 in `RewriteTensorize` post processor. I think this output can potentially 
cause the same problem, we can address it if we have consensus on the current 
logging interface change.
   
   CC @junrushao @vinx13 
   
   


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