Skip to content

Conversation

optimisan
Copy link
Contributor

Attempt to fix the compile-time regression introduced by #125703

This seems to make it better on my machine, but I cannot say for sure as the times keep changing (even taking an average over multiple runs)

@optimisan
Copy link
Contributor Author

@nikic could you check with the tracker bot?

The current procedure to port passes to the NPM is to extract the logic out to an implementation class and create legacy and new (PM) passes that wrap over the implementation class. This introduces the Impl object construction and method call overheads for every pass.

Another approach would be to keep the legacy pass as-is and wrap the new pass over the legacy pass, which would keep the legacy path relatively free of the Impl reference.

@nikic
Copy link
Contributor

nikic commented Feb 7, 2025

It doesn't make any difference: https://llvm-compile-time-tracker.com/compare.php?from=2f7d3ec02349d4503e1fa8c54665025eb4f8e173&to=830818cb44a1e239cfc40035b4a5963c3bd41b43&stat=instructions:u

You can use valgrind to profile locally in order to determine the root cause. Using z51.c from llvm-test-suite may be a good test case.

@optimisan
Copy link
Contributor Author

optimisan commented Feb 7, 2025

Cool, thanks.
And I'll revert that.

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