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

[Dy2stat] Add Basic Support for Grammar 'return' #25176

Merged
merged 6 commits into from
Jun 29, 2020

Conversation

zhhsplendid
Copy link
Member

@zhhsplendid zhhsplendid commented Jun 23, 2020

PR types

New features

PR changes

Others

Describe

This PR added basic support for 'return' grammar in dy2stat. It supports the control flow of 'return'.

The basics idea is using a return value variable to store the early return statements and boolean state variables with if-else to skip the statements after the return statements.

This PR is very basic support. There are some corner cases I didn't develop/test. For example, 'return None', 'return different length of variables', 'return non-tensor and tensor together', 'no return statement'. These corner cases will be done in my next PRs. Target date is this week.

Note:

  1. for the unit test, I changed test_program_translator.py because the StaticCode of dyfunc_with_if_else will change. To guarantee the correctness of dyfunc_with_if_else, I also run it in TestRecursiveReturn in test_return.py.

  2. I commented the early return code in bert_dygraph_model.py because 'return different length of variables' is unsupported now. I also know that there are some other models used early return and we didn't enable it in the unit test. I will add support for it in next PRs and then re-enable those tests.

@paddle-bot-old
Copy link

Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.

Copy link
Contributor

@liym27 liym27 left a comment

Choose a reason for hiding this comment

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

LGTM for the rest

return self.count_return[func_node]

def set_func_return_count(self, func_node, count):
self.count_return[func_node] = count
Copy link
Contributor

Choose a reason for hiding this comment

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

This function set_func_return_count doesn't seem to be called.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I found it. I will remove in my next PR which supports various-length return. Indeed it is already deleted in my working station.

Copy link
Contributor

@liym27 liym27 left a comment

Choose a reason for hiding this comment

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

LGTM

@zhhsplendid zhhsplendid merged commit 6f631a2 into PaddlePaddle:develop Jun 29, 2020
zhhsplendid added a commit that referenced this pull request Jun 30, 2020
Support Various-Length Return Grammar in Dy2stat. This PR is a follow-up of #25176 .

The basic idea is putting no-value placeholder variables at `return` statement to make all `return` statement have same length, after that the static graph can have fixed fetch output (code at return_transformer.py). Then remove those no-value placeholder when we finally return dygraph result (code at partial_program.py).

However, various length return in Bert model is still not supported. The dy2stat can change the code as I wish but some ops which check shape at compile time (e.g. Reshape, MatMul) will throw error because of the no-value-placeholder may not have the required shape. Is this a matter? To me, those no-value placeholder will be replaced as really values meeting shape requirements at run time, so I think the solution should be some way to do the compile-time checking. By the way, every time when we have dynamic shape, it often causes problem in dy2stat. We should find a way to handle it in the future.

Fixing various return in Bert is my TODO thing and I will also find some other existing models for verification.
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