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

Fixes #2358. Added to the reducer the ability to remove a function t… #2361

Merged
merged 4 commits into from
Feb 8, 2019

Conversation

afd
Copy link
Contributor

@afd afd commented Feb 7, 2019

…hat is not directly called. Factored out some code from the optimizer to help with this.

… function that is not directly called. Factored out some code from the optimizer to help with this.
Copy link
Collaborator

@s-perron s-perron left a comment

Choose a reason for hiding this comment

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

I would like to see a small change to make the new utility function more robust.

Is there a requirement that spirv-reduce work on all spir-v shader, or just a particular subset? In particular, if LinkageAttributes is allowed, there should be a test using it.

source/opt/eliminate_dead_functions_util.h Outdated Show resolved Hide resolved
std::vector<std::unique_ptr<ReductionOpportunity>> result;
// Consider each function.
for (auto& function : *context->module()) {
if (context->get_def_use_mgr()->NumUses(function.result_id()) > 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm trying to think of cases where this might leave a function that can be removed. Recursion is not allowed, so that is not a problem. OpName will be removed by another reduction opportunity, so that will not be a problem.

The only thing that could be a problem are decorations. Right now I do not see any decorations that would cause you a problem. LinkageAttributes should force the function to be kept. FuncParamAttr is only used for kernels, which I presume you do not care about.

I think this is safe, and if we see a specific decoration in the future that is keeping it alive, then we should update at that time. Sorry, wrote this as I was thinking about it.

Copy link
Contributor

Choose a reason for hiding this comment

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

The recursion restriction is actually added by Vulkan and is not core to SPIR-V. Not sure if this should only handle Vulkan cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In general, where removal of Xs is blocked due to Ys not being removed, we should gradually file issues for, and then add features to, remove Ys. So while we definitely need to think more on removal of decorations, that should not affect this pass.

The issue of recursion is potentially interesting and I guess would be a problem if other passes are not able to break recursive cycles (by removing OpCall instructions).

I suggest we revisit that in future in response to modules that don't reduce well due to this, if we find them.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree. Keep it simply for now, and see how all of the reduction opportunities work together. Improve as needed.

@afd
Copy link
Contributor Author

afd commented Feb 8, 2019

Clang format checks are to do with changes elsewhere.

@afd afd merged commit 34c5ac6 into KhronosGroup:master Feb 8, 2019
@afd afd deleted the remove_unused_functions branch February 8, 2019 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants