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

[SimplifyCFG][PhaseOrdering] Defer lowering switch into an integer range comparison and branch until after at least the IPSCCP #132

Closed

Conversation

Amanieu
Copy link
Member

@Amanieu Amanieu commented Feb 26, 2022

That transformation is lossy, as discussed in
llvm#53853
and rust-lang/rust#85133 (comment)

This is an alternative to D119839,
which would add a limited IPSCCP into SimplifyCFG.

Unlike lowering switch to lookup, we still want this transformation
to happen relatively early, but after giving a chance for the things
like CVP to do their thing. It seems like deferring it just until
the IPSCCP is enough for the tests at hand, but perhaps we need to
be more aggressive and disable it until CVP.

Fixes llvm#53853
Refs. rust-lang/rust#85133

Reviewed By: nikic

Differential Revision: reviews.llvm.org/D119854

wweiandrew and others added 2 commits February 26, 2022 23:44
Based on original tests from D119839.

See llvm#53853
…nge comparison and branch until after at least the IPSCCP

That transformation is lossy, as discussed in
llvm#53853
and rust-lang/rust#85133 (comment)

This is an alternative to D119839,
which would add a limited IPSCCP into SimplifyCFG.

Unlike lowering switch to lookup, we still want this transformation
to happen relatively early, but after giving a chance for the things
like CVP to do their thing. It seems like deferring it just until
the IPSCCP is enough for the tests at hand, but perhaps we need to
be more aggressive and disable it until CVP.

Fixes llvm#53853
Refs. rust-lang/rust#85133

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D119854
@nagisa
Copy link
Member

nagisa commented Feb 26, 2022

Is this really something we must backport? I don't recall us doing so all that often, except in the cases where it fixes a serious regression or something of the similar nature.

@Amanieu
Copy link
Member Author

Amanieu commented Feb 27, 2022

I'd rather not wait another 6 months until LLVM 15 to get this optimization, but if you feel strongly about it then I'm happy to close this.

@nikic
Copy link

nikic commented Feb 27, 2022

There's an upstream backport request for this change. If you can do a perf run to sanity-check this change, I'll approve the upstream backport, so this will be part of LLVM 14 and we don't have to diverge.

@nikic
Copy link

nikic commented Feb 27, 2022

Perf run started in rust-lang/rust#94424.

I'd also like to have an answer to rust-lang/rust#85133 (comment), so I can check whether this actually fixes the problem it is supposed to fix.

@nikic
Copy link

nikic commented Mar 3, 2022

As this doesn't actually address the original issue, I don't think it makes sense to backport this. I have some patched pending that do (together with this) fix it, but I don't think we'll want to backport the whole stack.

@nikic nikic closed this Mar 3, 2022
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.

5 participants