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.

Sign up for GitHub

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

Jump to bottom

Switch PLT default to "yes" for all targets except x86_64. #581

Closed
1 of 3 tasks
pnkfelix opened this issue Jan 26, 2023 · 4 comments
Closed
1 of 3 tasks

Switch PLT default to "yes" for all targets except x86_64. #581

pnkfelix opened this issue Jan 26, 2023 · 4 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Jan 26, 2023 •
edited
Loading

Proposal

Back in 2018 with PR rust-lang/rust#54592, Rust changed to disable the procedure linkage table (PLT) by default, and the only way to opt back into enabling the PLT was via an unstable nightly-only debug flag, -Zplt=yes.

According to some experts on the instruction encodings, this is only an optimization for x86_64. As stated on PR rust-lang/rust#106380 (which proposed turning the global default to enable PLT for all targets, aka "default to -Zplt=yes"):

On x86-64, if the target symbol is preemptible, there is an R_X86_64_GLOB_DAT relocation, and the (very minor) optimization works as intended. However, if the target is non-preemptible, i.e. the target is resolved to the same component, this is actually a pessimization due to
the longer instruction.

PR rust-lang/rust#54592 only did its analysis against x86_64 performance, and we did find that disable PLT was a win there. So, if we are going to change the PLT default, we probably should ensure that x86_64 keeps the existing behavior.

(Spawned off of rust-lang/rust#106380 (comment) , where @nikic has provided an deeper analysis, that recommends the approach described in this MCP.)

Mentors or Reviewers

I would be willing to mentor/review this work.

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
@pnkfelix pnkfelix added T-compiler Add this label so rfcbot knows to poll the compiler team major-change A proposal to make a major change to rustc labels Jan 26, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jan 26, 2023

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Jan 26, 2023
@pnkfelix pnkfelix mentioned this issue Jan 26, 2023
Closed
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Feb 3, 2023
@MaskRay
Copy link

MaskRay commented Feb 21, 2023

I prefer to revert the behavior toggle part of the original patch and default to -Z plt=yes and match GCC/Clang. -Z plt=yes for all targets except ELF x86-64 is still better than the current status quo.

I as an llvm-project contributor was really annoyed by the comments to my legitimate commits caused by rustc choices.

@nikic
Copy link
Contributor

nikic commented Feb 21, 2023

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Feb 21, 2023
@apiraino
Copy link
Contributor

apiraino commented Mar 7, 2023

@rustbot label -final-comment-period +major-change-accepted

@apiraino apiraino closed this as completed Mar 7, 2023
@rustbot rustbot added major-change-accepted A major change proposal that was accepted to-announce Announce this issue on triage meeting and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Mar 7, 2023
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Mar 23, 2023
@durin42 durin42 mentioned this issue Apr 5, 2023
Merged
durin42 added a commit to durin42/rust that referenced this issue Jun 22, 2023
@durin42
rustc_session: default to -Z plt=yes on non-x86_64
dfc5218 
Per the discussion in rust-lang#106380 plt=no isn't a great default, and
rust-lang/compiler-team#581 decided that the default should be PLT=yes
for everything except x86_64. Not everyone agrees about the x86_64 part
of this change, but this at least is an improvement in the state of
things without changing the x86_64 situation, so I've attempted making
this change in the name of not letting the perfect be the enemy of the
good.
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 23, 2023
@bors
Auto merge of rust-lang#109982 - durin42:plt-no-x86_64-only, r=nikic
c79d6be 
rustc_session: default to -Z plt=yes on non-x86_64

Per the discussion in rust-lang#106380 plt=no isn't a great default, and rust-lang/compiler-team#581 decided that the default should be PLT=yes for everything except x86_64. Not everyone agrees about the x86_64 part of this change, but this at least is an improvement in the state of things without changing the x86_64 situation, so I've attempted making this change in the name of not letting the perfect be the enemy of the good.

Please let me know if I've messed this up somehow - I'm not wholly confident I got this right.

r? `@nikic`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@pnkfelix @nikic @MaskRay @apiraino @rustbot