Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ARITH] Migrate simplifier to new infra #3368

Merged
merged 1 commit into from
Jul 1, 2019
Merged

Conversation

tqchen
Copy link
Member

@tqchen tqchen commented Jun 13, 2019

Migrate the current usage of simplifier to new infra part of #2588

After this PR. We are no longer dependent on HalideIR's Simplifier, and completely relies on the new integer analysis infrastructure. We might get certain regressions due to slightly different behavior, although the general infra will head to a better direction as we continue to improve the new consistent simplification infrastructure.

@tqchen tqchen changed the title migrate simplifier to new infra [ARITH] Migrate simplifier to new infra Jun 13, 2019
sgrechanik-h added a commit to sgrechanik-h/tvm that referenced this pull request Jun 19, 2019
@tqchen tqchen force-pushed the arith branch 2 times, most recently from 47a1a33 to ac5ec4b Compare June 20, 2019 17:50
@tqchen tqchen force-pushed the arith branch 7 times, most recently from 25ec955 to 7f7efe8 Compare June 30, 2019 22:59
@tqchen
Copy link
Member Author

tqchen commented Jul 1, 2019

cc @dmlc/tvm-team

bool target_is_non_neg = expr_map_[target_var].can_prove_non_negative();

if (is_greater_) {
result_ += 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this may be wrong: if we consider x*2 >= -1, then it will be transformed into x >= 0 + 1 which excludes x = 0.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bound deduction may allow relaxation and is not guaranteed to be tight

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I agree we could start to think about generating tighter bound if possible(by looking into signs)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is wrong, because in this case it is not a relaxation, but rather an overtightening, which is unsound.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I meant overtightening, as documented by the API note, we want to find a set in which the condition is always satisfied, so we can eliminate the condition by constraining the loop within that range.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, ok, that makes sense. However I think the DeduceBound function may return an approximation which is not a subset of the true set, because it also performs relaxation. I'm not sure, but I think it might break loop partitioning in some cases.

@tqchen tqchen merged commit 4273e46 into apache:master Jul 1, 2019
@tqchen
Copy link
Member Author

tqchen commented Jul 1, 2019

Thanks, @sgrechanik-h , this PR is now merged

@sgrechanik-h
Copy link
Contributor

By the way, I'm a bit concerned that this and some other PRs were merged without sufficient review and discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants