Skip to content

Codegen Overloaded LLVM intrinsics based on their name#157145

Open
sayantn wants to merge 2 commits into
rust-lang:mainfrom
sayantn:overloaded-intrinsics
Open

Codegen Overloaded LLVM intrinsics based on their name#157145
sayantn wants to merge 2 commits into
rust-lang:mainfrom
sayantn:overloaded-intrinsics

Conversation

@sayantn

@sayantn sayantn commented May 30, 2026

Copy link
Copy Markdown
Contributor

This is a continuation of #140763 - now codegenning overloaded LLVM intrinsics based on their name too. This PR parses the link_name of the LLVM intrinsics for the type parameters, partially inverting getMangledTypeStr and getIntrinsicNameImpl from LLVM.

There is the concern that @nikic's work on LLVM intrinsics might remove the name mangling, but we can just retain that from the Rust side. I mean even though the LLVM IR wouldn't have the mangling, but we can require that the Rust link_name argument contain the mangling. This shouldn't break anything, as existing code already has the name mangling.

There is also the concern that this cannot parse TargetExt types and non-literal struct types, as their mangling contains their name. If needed in future, we can maybe hardcode some known TargetExt types, but currently we don't support it. It also kinda helps that Rust currently cannot handle TargetExt types. The named struct one is not that big of a problem because courtesy of #140763 we can already repack structs.

I have not added support of LLVM byte type because it is only available in LLVM22, and we support min-LLVM version 20 afaik.

I prefer this approach over the IITDesc approach highlighted in #140763 because this approach allows code like

#[link_name = "llvm.sqrt.v8bf16"]
fn foo(a: u16x8) -> u16x8;

which pairs up with the autocasts of #140763 to give a nice way to call overloaded intrinsics on bf16. Also this approach is a lot less work and more resilient to LLVM changes than the IITDesc approach.

One important change - the parsing doesn't account for LLVM typed pointers, which were deprecated in LLVM15 and removed in LLVM17, so I didn't bother putting support for them. So, I also removed all uses of typed pointers from the tree.

r? @dianqk as you might have more of a context on this due to reviewing the last 2 PRs
cc @nikic

@rustbot

rustbot commented May 30, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

The Rustfmt subtree was changed

cc @rust-lang/rustfmt

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels May 30, 2026
@rust-log-analyzer

This comment has been minimized.

@sayantn sayantn force-pushed the overloaded-intrinsics branch from ef6fdb9 to a399a07 Compare May 30, 2026 08:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants