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

Better dominators #29140

Merged
merged 1 commit into from
Oct 5, 2018
Merged

Better dominators #29140

merged 1 commit into from
Oct 5, 2018

Conversation

Keno
Copy link
Member

@Keno Keno commented Sep 11, 2018

This commit replaces the naive algorithm for replacing dominator
trees by a faster implementation based on the Semi-NCA algorithm
(reference in the code comments). LLVM recently switched to this
algorithm and found it to be faster in practice than SLT (which
it used before). It is also slightly easier to implement. More
importantly though, it should easily extend to dynamic dominators.

I'm hoping this will fix the performance problems with constructing
dominators noted in #25927 as well as providing the basis for a
dynamic dominator implementation to fix #29107.

Current status: Bootstraps fine. Need to run more tests and look at the performance characteristics.

function construct_domtree(cfg::CFG)
idoms = SNCA(cfg)
nidoms = naive_idoms(cfg)
@assert idoms == nidoms
Copy link
Member

Choose a reason for hiding this comment

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

I'm confused about what's happening here... you construct idoms and nidoms by different algorithms but they must be the same. Is this just here temporarily for debugging?

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 the naive way to construct it will go away once I'm convinced it's correct

@Keno
Copy link
Member Author

Keno commented Sep 12, 2018

@timholy With this branch compile time of your script in #25927 is down to about 11 seconds on my machine.

@oscardssmith
Copy link
Member

Is DOM still the bottleneck, or did it move to something else?

@Keno
Copy link
Member Author

Keno commented Sep 12, 2018

(numbers are after taking out the old algorithm and assert of course)

@timholy
Copy link
Member

timholy commented Sep 12, 2018

Awesome! Did you add more to this branch? I actually gave it whirl yesterday and it was considerably improved, but nowhere near 11s.

@timholy
Copy link
Member

timholy commented Sep 12, 2018

Oh, I now see your second comment. That's really great news!

@Keno
Copy link
Member Author

Keno commented Oct 3, 2018

I'm doing a PkgEval run right now (with the assert still in) and plan to merge shortly thereafter if that comes back green (at which point I'll take out the assert also).

@vtjnash
Copy link
Member

vtjnash commented Oct 3, 2018

I haven't reviewed, but yay! (also, don't forget to drop the "WIP" from the issue title and commit message).

@Keno
Copy link
Member Author

Keno commented Oct 4, 2018

PkgEval came back green. I'll rebase this to remove the assert and remove the WIP.

This commit replaces the naive algorithm for replacing dominator
trees by a faster implementation based on the Semi-NCA algorithm
(reference in the code comments). LLVM recently switched to this
algorithm and found it to be faster in practice than SLT (which
it used before). It is also slightly easier to implement. More
importantly though, it should easily extend to dynamic dominators.

This fixes the preformance problems in dominator construction noted
in #25927 and should provide a basis for a dynamic dominator
implementation to fix #29107.
@Keno Keno changed the title WIP: Better dominators Better dominators Oct 4, 2018
@Keno Keno merged commit 8ff75ad into master Oct 5, 2018
@StefanKarpinski StefanKarpinski deleted the kf/snca branch October 5, 2018 00:18
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.

Compiler bug uncovered by BaseBenchmarks
5 participants