Add `target_feature_available_at_call_site`

[workingjubilee]

Proposal

std::simd is in the awkward situation of being an attempt to have reasonable codegen for target-independent code, yet wanting to exploit highly target-specific and even compiler-invocation-specific codegen details that our precompiled std is a fairly poor fit for.

We have three problems that cannot be addressed by std's existing dynamic feature detection code or cfg!(target_feature = "..."):

1. Target features are abstractions. LLVM cannot relate them to the complicated code used to inspect the architectural registers which encode correlating bits, so it cannot see a feature is statically available and remove dynamic feature detection code.
2. #[cfg] and cfg! resolve their predicates at the time of AST expansion, so when we precompile std, we have the answer to those questions and cannot delay the answer to "after inlining".
3. Even the lightest dynamic feature detection code is enormously costly in performance, defeating the purpose of using it inside std::simd.

While we can pursue other extensions of LLVM's capabilities, a decent amount of std::simd's needs can be implemented in library code with one extension to Rust's list of directly-known intrinsics: target_feature_available_at_call_site. This has been implemented in rust-lang/rust#158713.

This intrinsic asks the question in its name and then returns a bool, allowing introducing a branch on whether this feature is known to be available in a "static" (known-at-compile-time) fashion. It relies on some integration with the codegen backend so that it can correctly answer the question after inlining. We plan to upstream the custom LLVM pass its experimental form depends on as soon as feasible. Dead code removal takes care of the rest, allowing the optimized implementation to remain despite being part of std.

It is acceptable for this intrinsic to be implemented as "always return false", as it is a quality-of-implementation detail that is the responsibility of the codegen backend. For soundness, the answer of true must be correct, as it will gate the use of intrinsics based on that target feature.

The current plan is to only use this internally and to pursue an RFC or other appropriate process when this has more stable exposure. For now, we ask if this is a reasonable addition to the compiler and explicitly invite opsem to be part of this decision: cc @rust-lang/opsem

Mentors or Reviewers

• @nikic and everyone accursed to be involved in codegen
• someone on T-opsem, probably
• @workingjubilee can probably glance at it and nod sagaciously about parts that aren't directly in backends

Process

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

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (1 active)

• debugging-the-llvmir

Managed by @rustbot—see help for details.

[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.

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

Concerns can be lifted with:

@rustbot resolve reason-for-concern

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

cc @rust-lang/compiler

[workingjubilee]

@rustbot concern debugging-the-llvmir

@nikic mentioned that the implementation depending on a custom pass could make debugging rustc's generated LLVMIR harder. We intend to get rid of that pass in favor of a real intrinsic as quickly as possible, but if Nikita prefers strongly the implementation could be blocked on having LLVM implement it directly instead of just assurances. Certainly it would be reasonable to block this until we at least have a draft up against LLVM for the proposal as an intrinsic. I'm raising this concern here to allow Nikita to resolve it by accepting it on either of these terms ("promises are fine", "draft, please", or "no, actually landed upstream first").

[RalfJung]

@rustbot second

This sounds good to me from an opsem perspective. We could bikeshed the name and implementation details, but the semantics LGTM.