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
gh-101282: move BOLT config after PGO #104493
Conversation
FWIW this change builds up to a build system refactor that fixes some bugs/quirks with BOLT and enables the use of BOLT on libpython, which results in significant pyperformance impact. The remaining rough set of commits are available in #101093. |
Misc/NEWS.d/next/Build/2023-05-14-19-06-13.gh-issue-104492.7S6WNO.rst
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with nit comment
But for future work, I would like to say.
For the BOLT, it could also be able to be enabled without enabling PGO. (Might be a weird configuration, but someone may need it)
c15ac80
to
077503c
Compare
A future commit will make bolt's configure logic depend on PGO state. I'm moving the block in a standalone commit to make the diff easier to read. skip news
077503c
to
f9fdde5
Compare
Agree that we should support {none, either, both} configs. But it may require a bit of work to get there. I'll keep this in mind and try to implement it. I think the refactoring I'm doing to the PGO/BOLT make rules should make this vastly easier to achieve. |
|
This comment was marked as duplicate.
This comment was marked as duplicate.
Post-merge review: LGTM @indygreg: please don't force-push; it does not play well with reviews on GitHub. If you haven't already, please take a look at the devguide, specifically Life of a Pull Request |
A future commit will make bolt's configure logic depend on PGO state. I'm moving the block in a standalone commit to make the diff easier to read.