ekalda commented on pull request #9331: URL: https://github.com/apache/tvm/pull/9331#issuecomment-966241622
> > if you genuinely disagree feel free to merge without test coverage > > My position is to keep the assert (as originally added by @ashutosh-arm -- not a request for a change). I only oppose removing it on the basis it is not tested. Im happy to do it in a follow up if thats what @ashutosh-arm wants to do here ? > > > his has happened on other PRs I've reviewed. > > Hence the questioning here, because this exact point is questioned elsewhere but not here. Other places we committed to follow up if that is direction we want to take. cc : @ekalda @mbaret. Im pretty sure if we agree on this point we will do the necessary changes. > > > working on the assumption we want the code to continue working for the forsee-able future > > Im pretty sure we all want this -- just being lenient on internal asserts -- that is all. Yes, I think we agreed to add the tests in a follow-up PR if we decide to test the internal asserts in the future, so it would make sense for this PR to go in as it is as well. My (unchanged) view on the topic is that I agree with @manupa-arm that we should test the user facing asserts, but not the simple developer facing asserts. While it is a good practice to test all the functionality, I think we should always evaluate these kind of guidelines in the context of the specific project if we want to avoid getting stuck in dogmas. It is a valid point that perhaps we should remove the unreachable asserts then, but I think TVM is very much still a project in progress and I have found the developer facing asserts very useful, so I don't think they do any harm. In general, the NPU side of codebase is in constant flux at the moment, so a lot of tests means a lot of extra code to maintain and makes making changes harder. So at that stage I think there is more harm in testing ICHECKs than benefits in a from maintenance overhead. -- 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]
