[opt] Eliminate assertions with non-zero const conditions

[xumingkuan]

Thanks for @archibate 's idea!
Related PR = #839 (comment)
Before:

After:

WDYT if we optimize a kernel to 0 statements... I set it to 1 statement to avoid division by 0 here. But it's causing too much "improvement" to the geometric mean: nearly 1.02x.

[Click here for the format server]

[xumingkuan]

Oh I pushed to the main repo by accident. I think it doesn't matter if I delete this branch after squash and merge...

[archibate]

Cool!

[archibate]

Btw, could you also perform a test comparing with ti.cfg.check_out_of_bound = False?

[archibate]

Oh I pushed to the main repo by accident. I think it doesn't matter if I delete this branch after squash and merge...

Congratuation on gaining write-access! We need more discussion on how to make use of it instead of abuse of it. First of all, can a PR author with write-access merge PRs like this on their own without a confirm from the team leader? If we don't make restrictions on review, it will be hard to track BUG; if we restrict too much on review, will definitely increase @yuanming-hu's work as our community grows. We may want to merge some non-critical PRs without the leader's confirm if at least one reviewer approved? If so, write-access members will take more responsibility and their mind should be clear and be cation about mistakes like #879.

[yuanming-hu]

LGTM!

[yuanming-hu]

Oh I pushed to the main repo by accident. I think it doesn't matter if I delete this branch after squash and merge...

Congratuation on gaining write-access! We need more discussion on how to make use of it instead of abuse of it. First of all, can a PR author with write-access merge PRs like this on their own without a confirm from the team leader? If we don't make restrictions on review, it will be hard to track BUG; if we restrict too much on review, will definitely increase @yuanming-hu's work as our community grows. We may want to merge some non-critical PRs without the leader's confirm if at least one reviewer approved? If so, write-access members will take more responsibility and their mind should be clear and be cation about mistakes like #879.

Thanks for thinking about this. I think having one review approval before merging would be good enough.

[xumingkuan]

Btw, could you also perform a test comparing with ti.cfg.check_out_of_bound = False?

I'm not sure what you mean. Could you please explain it in more detail? And I think ti.cfg.check_out_of_bound is False by default in release mode?

[archibate]

Oh I pushed to the main repo by accident. I think it doesn't matter if I delete this branch after squash and merge...

Congratuation on gaining write-access! We need more discussion on how to make use of it instead of abuse of it. First of all, can a PR author with write-access merge PRs like this on their own without a confirm from the team leader? If we don't make restrictions on review, it will be hard to track BUG; if we restrict too much on review, will definitely increase @yuanming-hu's work as our community grows. We may want to merge some non-critical PRs without the leader's confirm if at least one reviewer approved? If so, write-access members will take more responsibility and their mind should be clear and be cation about mistakes like #879.

Thanks for thinking about this. I think having one review approval before merging would be good enough.

Great! Let's merge this then. And later with #839.

[archibate]

Btw, could you also perform a test comparing with ti.cfg.check_out_of_bound = False?

I'm not sure what you mean. Could you please explain it in more detail? And I think ti.cfg.check_out_of_bound is False by default in release mode?

Oh, did ti.init(debug=True) caused check_oob? Sorry for misunderstanding, seems it's only enabled in test_assert now.

[xumingkuan]

The 0 statements was probably due to the mismatch of tests... I can't reproduce it now.