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

[onert] Add check for topological order validity #12602

Merged
merged 1 commit into from
Feb 7, 2024
Merged

[onert] Add check for topological order validity #12602

merged 1 commit into from
Feb 7, 2024

Conversation

Aeren1564
Copy link
Contributor

This commit introduces the following functions

  • assertValidTopologicalOrder
  • assertValidBackwardTopologicalOrder

which will catch any potential bugs on forward or backward topological ordering used in onert.

ONE-DCO-1.0-Signed-off-by: YongHyun An [email protected]


From draft #12562

@Aeren1564 Aeren1564 mentioned this pull request Feb 5, 2024
2 tasks
@Aeren1564
Copy link
Contributor Author

Aeren1564 commented Feb 5, 2024

The model on #12325 (comment) is now correctly rejected as follows.

Error during nnfw_session::train_prepare : Invalid backward topological order: inversion between @45 and @46

Comment on lines +162 to +171
if (p > q)
throw std::runtime_error{
"Invalid " + order_type + " topological order: inversion between @" +
std::to_string(index.value()) + " and @" + std::to_string(use.value())};
Copy link
Contributor Author

@Aeren1564 Aeren1564 Feb 5, 2024

Choose a reason for hiding this comment

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

There is an inversion between node u and v in an ordering if there is an edge from u to v and v preceeds u.

A valid topological order should not contain any inversion.

Comment on lines 171 to 187
void TrainableGraph::assertValidBackwardTopologicalOrder(
std::vector<ir::OperationIndex> order) const
{
std::reverse(order.begin(), order.end());
assertValidTopologicalOrder(order, "backward");
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

An order is a backward topological order if and only if its reverse is a forward topological order.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This has been moved to

if (!is_forward)
std::reverse(order.begin(), order.end());

@Aeren1564 Aeren1564 marked this pull request as ready for review February 5, 2024 08:16
@Aeren1564 Aeren1564 added approval: 2 Require at least 2 approvals PR/ready for review It is ready to review. Please review it. labels Feb 5, 2024
@Aeren1564 Aeren1564 requested review from jyoungyun and a team February 5, 2024 08:20
Comment on lines 131 to 133
void assertValidTopologicalOrder(const std::vector<ir::OperationIndex> &order,
const std::string &order_type) const;
void assertValidBackwardTopologicalOrder(std::vector<ir::OperationIndex> order) const;
Copy link
Contributor

Choose a reason for hiding this comment

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

From the name of assert..., are these for test only? If so, what about moving this into test code?

Copy link
Contributor Author

@Aeren1564 Aeren1564 Feb 6, 2024

Choose a reason for hiding this comment

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

I intended ONERT to throw error upon finding an invalid topological order.

Adding them as unittest instead would only catch some specific pre-determined cases and ONERT could still end up using some invalid topological order.

Copy link
Contributor

@glistening glistening Feb 6, 2024

Choose a reason for hiding this comment

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

IMHO,

  1. I believe backwardTopologicalOrder should always return correct answer. It is well-known problem. We already have several ones from compiler frontend in this repo, and internal repo.
  2. If there was a bug, I would add regression testcase for backwardTopologicalOrder with your validate function.

Copy link
Contributor

@zetwhite zetwhite left a comment

Choose a reason for hiding this comment

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

I read the code. The logic looks good to me. 👍

But I agree with this opinion - https://github.com/Samsung/ONE/pull/12602/files#r1479151257

If this code is only for ensuring that topological sorting is done right,
I'd prefer to make it run only in debug mode(sorry but i either don't know how to make specific code run only on debug mode) or move it into the test.

@Aeren1564
Copy link
Contributor Author

Aeren1564 commented Feb 6, 2024

If this code is only for ensuring that topological sorting is done right,
I'd prefer to make it run only in debug mode

May I ask why? I think I expect ONERT to reject such incorrect result regardless of I'm in debug mode or not, and I believe this check is not a performance bottleneck either.

jyoungyun
jyoungyun previously approved these changes Feb 6, 2024
Copy link
Contributor

@jyoungyun jyoungyun left a comment

Choose a reason for hiding this comment

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

LGTM

std::vector<ir::OperationIndex> TrainableGraph::topolSortOperations() const
{
return _graph.topolSortOperations();
auto ret = _graph.topolSortOperations();
assertValidForwardTopologicalOrder(ret);
Copy link
Contributor

Choose a reason for hiding this comment

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

I prefer to use verify instead of assert for the function name, but this depends on the developer's taste. So your function naming is okay. In addition, the assertValidTopologicalOrder function can be called directly, but the current code is also good. :)

@zetwhite
Copy link
Contributor

zetwhite commented Feb 6, 2024

May I ask why? I think I expect ONERT to reject such incorrect result regardless of I'm in debug mode or not, and I believe this check is not a performance bottleneck either.

In my understanding overall view is that :

  1. topolSortOperations and btopolSortOperations do the sorting and its' sorting algorithm should guarantee that order, somehow.
  2. This code is kind of an additional validation check to verify sorting algorithm is correct.

In the point of 2, this validation looks like a test code to verify sorting algorithm. And it is meaningful for onert developers not user. If user figured out that btopol is wrong, there is no option except waiting the onert core is fixed.

So I thought the direction that this logic runs for only debug mode for developer, to get help to update sorting algorithm.

I don't know the detailed thing about this issue. Is there a near-plan to fix btopolSortOperations to resolve this - #12325 (comment) ?


I don't have a strong opinion about this.
So, I could approve this draft as-is!

Comment on lines 131 to 133
void assertValidTopologicalOrder(const std::vector<ir::OperationIndex> &order,
const std::string &order_type) const;
void assertValidBackwardTopologicalOrder(std::vector<ir::OperationIndex> order) const;
Copy link
Contributor

@glistening glistening Feb 6, 2024

Choose a reason for hiding this comment

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

IMHO,

  1. I believe backwardTopologicalOrder should always return correct answer. It is well-known problem. We already have several ones from compiler frontend in this repo, and internal repo.
  2. If there was a bug, I would add regression testcase for backwardTopologicalOrder with your validate function.

This commit introduces the following functions

- assertValidTopologicalOrder
- assertValidBackwardTopologicalOrder

which will catch any potential bugs on forward or backward topological ordering used in onert.

ONE-DCO-1.0-Signed-off-by: YongHyun An <[email protected]>
Copy link
Contributor

@jyoungyun jyoungyun left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@ragmani ragmani left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@hseok-oh hseok-oh left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@glistening glistening left a comment

Choose a reason for hiding this comment

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

LGTM

@glistening glistening merged commit 1ef4072 into Samsung:master Feb 7, 2024
9 checks passed
@Aeren1564 Aeren1564 deleted the add_toposort_check branch February 7, 2024 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approval: 2 Require at least 2 approvals PR/ready for review It is ready to review. Please review it.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants