Attribute to control frame pointers

[tgross35]

Background

The standard library is distributed with -Cforce-frame-pointers=true, which was added in rust-lang/rust#122646 to aid profiling. This is a net positive but there are some cases where having frame pointers doesn't make as much sense. compiler_builtins has a handful of small functions that can't be inlined because they must be a callable symbol, but are tiny enough that updating the frame pointer contributes to a significant portion of the instruction count.

The most notable example is our current fma implementation with runtime feature detection on x86. This would usually be three instructions, but tracking the frame pointer triples this count (involves two noninlineable symbols).

More background: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/significant.20mul_add.20perf.20regression.20since.20nightly-2025-03-06/with/516632450

Proposal

LLVM's frame-pointer attribute is function-level, so we can add an unstable attribute to match them.

#![feature(frame_pointer_attribute)]

#[frame_pointer(none)]     // "frame-pointer"="none"
#[frame_pointer(reserved)] // "frame-pointer"="reserved"
#[frame_pointer(non_leaf)] // "frame-pointer"="non-leaf"
#[frame_pointer(all)]      // "frame-pointer"="all"

These will override the -Cforce-frame-pointers setting for that crate.

LLVM docs: https://llvm.org/docs/LangRef.html#function-attributes.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them
here. You can put your own name here if you are planning to mentor the
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.

[rustbot]

Important

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.

Concerns or objections can formally be registered here by adding a comment.

@rfcbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rfcbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[workingjubilee]

I would object: This MCP would introduce a specific hammer in order to tap a specific nail in, but does not evaluate our existing hammers for fitness. Are they too oddly-shaped? So it needs evaluation of alternatives like compiling std with -Zunstable-options -Cforce-frame-pointers=non-leaf to determine whether this is required or beneficial or what.

[tgross35]

From discussion on Zulip it sounds like there is likely a better path here.