-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[Bazel] Export compiler-rt builtins sources #157200
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
Merged
Merged
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
nit: It looks like cmake uses the preprocessor here to resolve these values directly for the outputs. IIUC, prepending them to the sources could leak these defines to consumers. The
builtins_aarch64_srcsseems to be a final target, so it wouldn't be noticeable in the llvm build itself.Since these are
.Sfiles, I'm not sure how relevant this actually is. If it could be of concern, an alternative might be something like this which initially might seem inefficient but it appears that (at least with the toolchain i tested this with) it actually breaks after one iteration as the compiler comes first in this list (and the list itself has consistent ordering).llvm-project/compiler-rt/lib/builtins/CMakeLists.txt
Line 656 in 86ac4a0
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.
My thought was precisely that by keeping these as
.Sfiles we can haveclangdo this for us while assembling.Downstream, this pattern has been working well for some time, so I'm hesitant to change it to a more complex thing at this stage. We can revisit of course if anyone encounters problems with this approach.
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.
Ah yeah I did mean to keep the
.Sfiles but to use the preprocessor so that the defines don't somehow collide with someone that includes these files or theassembly.hfile. (Thelse.Sfile doesn't seem to have include guards).But tbh this seems more like something that might make more sense to change on the CMake side first if at all. Once the rule-based cc_toolchains in rules_cc get a bit more stable/widely used it might make sense to revisit this if those make it easier to get just a preprocessor, but at the moment just the echos seem like the better option if this works for current downstream usage already.
The bazel_skylib's template expansion isn't really an option here either as the usage of these macros is not something that can easily be substituted in via the template engine.
So I think this is good the way it is 👍