Add `target_feature_available_at_call_site`

Read the proposal and the implementation in rust-lang/rust#158713 first, then review the active debugging-the-llvmir concern. The issue is seeking compiler-team and opsem agreement on whether to add the intrinsic, with a second or resolved concerns marking progress rather than a code change.

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.