[GitHub] [incubator-tvm] tqchen commented on issue #5741: Upgrade AutoTensorCore as to a TIR Pass

[GitBox <gi...@apache.org>]

tqchen commented on issue #5741:
URL: https://github.com/apache/incubator-tvm/issues/5741#issuecomment-640244021


   Thanks @jcf94 . I agree that making a better approach for tensorization is important and we should continue to push that direction. 
   
   My specific issue is about what to do with the pass as in its current state now. Specifically, there are a few options:
   
   - A0: Temporarily remove AutoTensorCore, assuming it has limited usecase and most of the current TensorCore goes through the tensorcore intrinsics, add a better solution back later.
   - A1: Migrate the AutoTensorCore to TIR by pattern matching the loop nest(instead of the compute expression), so that it can becomes part of the TIR pass, replace the pass later once we have a better solution.
   - A2: Keep AutoTensorCore in its current location, which introduce a friction pt to the overall design itself, maintaining it as we refactor the code base while tolerating the design friction, remove it once we have a better solution.
   
   We can find that in all of these cases, the AutoTensorCore pass as it is will get removed eventually once we find a better solution. They have different pros and cons, for example, A2 brings a design friction pt to the overall architecture, and could cause problem if we want to release before we find a better solution. A0 is  the easiest for the developers, but also means the feature will be un-available until we find a better solution.  A1 maintains the codebase itself, while continues to migrating it to a better state that fits into the current design, of course it puts more demands on the developers themselves.
   
   This is an interesting case, the code itself becomes a technical debt that we need to pay as maintainers.  It is fun to develop new features. In the meanwhile, maintaining existing code, revisit the design and keep keep migrating them to a better infrastructure is equally important, if not more important for a healthy project. As all new features eventually become technical debts when other new features are added on top. It is important for us to keep infrastructure innovation and  refactoring to reduce the amount of key concepts back to minimum. So that we can more effectively evolve to deliver great new features.
   
   Would love to see thoughts wrt to the three options.
   
   
   
    
   
   
   
   


----------------------------------------------------------------
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:
users@infra.apache.org