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

Add -Z llvm_module_flag #116555

Merged
merged 1 commit into from Nov 15, 2023
Merged

Add -Z llvm_module_flag #116555

merged 1 commit into from Nov 15, 2023

Conversation

paulmenage
Copy link
Contributor

@paulmenage paulmenage commented Oct 9, 2023

Allow adding values to the !llvm.module.flags metadata for a generated module. The syntax is

-Z llvm_module_flag=<name>:<type>:<value>:<behavior>

Currently only u32 values are supported but the type is required to be specified for forward compatibility. The behavior element must match one of the named LLVM metadata behaviors.

This flag is expected to be perma-unstable.

@paulmenage
Copy link
Contributor Author

r?

@rustbot
Copy link
Collaborator

rustbot commented Oct 9, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot
Copy link
Collaborator

rustbot commented Oct 9, 2023

Error: Parsing assign command in comment failed: ...'' | error: specify user to assign to at >| ''...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 9, 2023
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

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

For rustc, perma-unstable compiler flags tend to mostly be used by people working on the compiler itself rather than features users might want to rely on. Could you explain a bit why you want to adjust LLVM module flags in this way?

Thanks! 🙂

Comment on lines +10 to +12
Currently only u32 values are supported but the type is required to be specified
for forward compatibility. The `behavior` element must match one of the named
LLVM [metadata behaviors](https://llvm.org/docs/LangRef.html#module-flags-metadata)
Copy link
Member

Choose a reason for hiding this comment

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

It might be good to have a practical example of why you might want to use this flag here.

Copy link

Choose a reason for hiding this comment

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

For setting the small data limit to 0 to prevent the use of .sdata (the purpose of this PR), the flag can be specified as -Zllvm_module_flag=SmallDataLimit:u32:0:Error

@paulmenage
Copy link
Contributor Author

My immediate motivation is that I'm working on an embedded system where I really need LLVM to not put symbols into the "small data segment" (.sdata and .sbss) but instead put each symbol in its own section as normal.

The platforms where LLVM supports small data segments each have their own way of controlling the threshold for what might get put in the small data segments. Three of them (MIPS, M68K, Hexagon) use LLVM arguments (although different args for each platform) so if I was targeting those platforms the existing -C llvm-args flag would be enough. RiscV (which is the platform I actually care about) uses an LLVM module flag (SmallDataLimit). So being able to set module flags would solve the problem here, in the same way that you can set LLVM arguments currently.

Possibly the better solution to the underlying problem would be a rustc flag, something like -C small-data-threshold, as in master...paulmenage:rust:small-data-limit.

But,

  • that seems rather more specific to my needs rather than generically useful
  • the tests to prove that it works are painful since it seems that some of the platforms are kinda non-deterministic in when they actually put things in the small data segments, regardless of what LLVM args are passed

So I figured that a module-flags analogue of the existing -C llvm-args option would fit in better with the existing compiler, and be less controversial.

@bors
Copy link
Contributor

bors commented Oct 19, 2023

☔ The latest upstream changes (presumably #115214) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors
Copy link
Member

r? @wesleywiser

@bors
Copy link
Contributor

bors commented Nov 8, 2023

☔ The latest upstream changes (presumably #117706) made this pull request unmergeable. Please resolve the merge conflicts.

Allow adding values to the `!llvm.module.flags` metadata for a generated
module.  The syntax is

`-Z llvm_module_flag=<name>:<type>:<value>:<behavior>`

Currently only u32 values are supported but the type is required to be
specified for forward compatibility.  The `behavior` element must match
one of the named LLVM metadata behaviors.viors.

This flag is expected to be perma-unstable.
@wesleywiser
Copy link
Member

Thanks @paulmenage! I agree, since we already have -C llvm-args, it makes sense to allow setting LLVM module flags as well.

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Nov 15, 2023

📌 Commit 2e6b575 has been approved by wesleywiser

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 15, 2023
@bors
Copy link
Contributor

bors commented Nov 15, 2023

⌛ Testing commit 2e6b575 with merge 0b24479...

@bors
Copy link
Contributor

bors commented Nov 15, 2023

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 0b24479 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 15, 2023
@bors bors merged commit 0b24479 into rust-lang:master Nov 15, 2023
12 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Nov 15, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0b24479): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.7% [0.7%, 0.7%] 1
Regressions ❌
(secondary)
2.2% [2.2%, 2.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.7% [0.7%, 0.7%] 1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.5% [-0.5%, -0.5%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.0% [-0.5%, 0.5%] 2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 674.873s -> 675.256s (0.06%)
Artifact size: 311.07 MiB -> 311.08 MiB (0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants