Codegen Overloaded LLVM intrinsics based on their name by sayantn · Pull Request #157145 · rust-lang/rust

sayantn · 2026-05-30T07:31:46Z

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 · 2026-05-30T07:31:49Z

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 · 2026-07-08T20:34:25Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

apiraino · 2026-08-19T14:19:16Z

cc @rust-lang/wg-llvm could you have a look here - when you have some time? thanks

dianqk · 2026-08-24T01:05:14Z

cc @rust-lang/wg-llvm could you have a look here - when you have some time? thanks

I will review this PR this week.

dianqk

LGTM. Thanks!

View changes since this review

dianqk · 2026-08-27T05:16:56Z

@bors r+

rust-bors · 2026-08-27T05:16:59Z

📌 Commit 36e3bbc has been approved by dianqk

It is now in the queue for this repository.

@nikic

…ianqk Codegen Overloaded LLVM intrinsics based on their name This is a continuation of rust-lang#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`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00076) and [`getIntrinsicNameImpl`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00165) 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 rust-lang#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 rust-lang#140763 because this approach allows code like ```rust #[link_name = "llvm.sqrt.v8bf16"] fn foo(a: u16x8) -> u16x8; ``` which pairs up with the autocasts of rust-lang#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

@nikic

…ianqk Codegen Overloaded LLVM intrinsics based on their name This is a continuation of rust-lang#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`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00076) and [`getIntrinsicNameImpl`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00165) 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 rust-lang#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 rust-lang#140763 because this approach allows code like ```rust #[link_name = "llvm.sqrt.v8bf16"] fn foo(a: u16x8) -> u16x8; ``` which pairs up with the autocasts of rust-lang#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

@nikic

…ianqk Codegen Overloaded LLVM intrinsics based on their name This is a continuation of rust-lang#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`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00076) and [`getIntrinsicNameImpl`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00165) 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 rust-lang#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 rust-lang#140763 because this approach allows code like ```rust #[link_name = "llvm.sqrt.v8bf16"] fn foo(a: u16x8) -> u16x8; ``` which pairs up with the autocasts of rust-lang#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

@nikic

…ianqk Codegen Overloaded LLVM intrinsics based on their name This is a continuation of rust-lang#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`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00076) and [`getIntrinsicNameImpl`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00165) 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 rust-lang#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 rust-lang#140763 because this approach allows code like ```rust #[link_name = "llvm.sqrt.v8bf16"] fn foo(a: u16x8) -> u16x8; ``` which pairs up with the autocasts of rust-lang#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

RalfJung · 2026-08-27T13:55:03Z

+pub unsafe fn overloaded_bf16_autocast(a: i16x8) -> i16x8 {
+    extern "unadjusted" {
+        #[link_name = "llvm.sqrt.v8bf16"]
+        fn foo(a: i16x8) -> i16x8;


I find this extremely confusing. What is going on here? The intrinsic actually has type <8 x bfloat> but we pass it an i16x8? Why should we allow such code...?

View changes since the review

I think the main motivation for this entire approach was ability to insert magic type casts for types that Rust does not support.

Of course, this is kind of moot with f16b being introduced in #160859.

(FWIW, I don't think what this PR does is a good idea, but I don't have time to fight it.)

Of course, this is kind of moot with f16b being introduced in #160859.

Yeah that seems to remove this part of the motivation. OTOH the old referenced PR also mentions

LLVM intrinsics that have types in their signature that can't be accessed from Rust (notable examples are the AMX intrinsics that have the x86amx type, and (almost) all intrinsics that have vectors of i1 types) can't be linked to at all. This is a (major?) roadblock in the AMX and AVX512 support in stdarch.

So the question is, will we have native types for those as well? We might have to, if they are relevant for ABIs we need to implement. But if they are only used for LLVM intrinsics, not for extern "C", then this PR may save us from adding that type. I don't know anything about x86amx, or whether there's a better way to deal with vectors of i1.

Another motivation seems to be dealing with LLVM intrinsics that change their signature -- how is stdarch supposed to import these? But this does works today so it seems the LLVM auto-upgrade for this is enough?

And then there's "finding signatures that are just wrong". But it seems that already landed in #140763.

On the list of downsides we have "keeping the long mangled LLVM names even after LLVM itself doesn't use them any more", if I understood correctly the plan for how to deal with @nikic's work on getting rid of the name mangling in LLVM. That seems like a silly end state and is clearly path-dependent -- if LLVM had removed the mangling 5 years ago, I doubt we'd accept a PR like this to add magic name mangling in the link_name string to indicate the "real" signature. So likewise I don't think we want to be in a state where we are keeping the name mangling alive long after LLVM dropped it.

I also couldn't find an MCP for this change. Should it have one? It's very backend-internal, but OTOH one of our main backend experts disagrees so it may be good to have a bit of a wider discussion. @dianqk seems fine with it.

The intrinsics name mangling has been in Rust for a long time, before #140763. IMO, this PR just helps handwriting intrinsics for people. This is fine with me.
I think we may want to find an approach to get rid of the name mangling after LLVM changed, even if we are not going to merge the PR.

But I'm curious about alternative implementation. Can we write a cargo out-of-tree plugin for the intrinsics name mangling? IIUC, since this is mostly used for stdarch, a standalone checking tool would be great.

The intrinsics name mangling has been in Rust for a long time, before #140763

demangle_type_str is new in this PR, so I am not sure what you mean. So far these mangled names are just forwarded opaquely to LLVM.

To clarify my position on this: I consider name mangling to be something of an implementation detail of LLVM, that Rust would ideally not need to expose. Instead of declaring something like #[link_name = "llvm.sqrt.v8bf16"], it is sufficient to use #[link_name = "llvm.sqrt"] and infer the mangled name from the function signature. This is how intrinsics are written in textual LLVM IR nowadays, you don't actually write out the mangling suffix, the parser infers it.

The motivation for inverting this, and instead make the mangling suffix (rather than the function signature) the source of truth is ability to insert automatic casts for types that Rust does not support. This is no longer relevant for bfloat, but still relevant for x86_amx. IMHO the proper way to handle that is to represent this as a special type in Rust, which has special ABI rules when passed to LLVM intrinsics. This does not have to be full support for the type like what is happening with f16b right now, but just the minimum to adjust its ABI (which I assume is something like a lang item?)

IMHO the proper way to handle that is to represent this as a special type in Rust, which has special ABI rules when passed to LLVM intrinsics. This does not have to be full support for the type like what is happening with f16b right now, but just the minimum to adjust its ABI (which I assume is something like a lang item?)

rust-lang/rfcs#4003 does this for two more types.

For types that don't get publicly exposed but only used internally, I think this doesn't need an RFC. Just a t-compiler MCP.

Rollup of 7 pull requests Successful merges: - #150075 (Implement clamp_to) - #157145 (Codegen Overloaded LLVM intrinsics based on their name) - #161866 (delegation: add tests fixating behavior of delegating to default trait implementations) - #161456 (reduce perf impact of scalar size checks) - #161730 (Improve type mismatch annotation for lets with block-wrapped initializers) - #161828 (Never type after-stabilization cleanup) - #161860 (atomicptr.rs test: remove unused import)

@nikic

…ianqk Codegen Overloaded LLVM intrinsics based on their name This is a continuation of rust-lang#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`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00076) and [`getIntrinsicNameImpl`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00165) 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 rust-lang#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 rust-lang#140763 because this approach allows code like ```rust #[link_name = "llvm.sqrt.v8bf16"] fn foo(a: u16x8) -> u16x8; ``` which pairs up with the autocasts of rust-lang#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

RalfJung · 2026-08-27T15:49:49Z

@bors try jobs=aarch64-gnu
(I think this may have failed the rollup.)

Codegen Overloaded LLVM intrinsics based on their name try-job: aarch64-gnu

RalfJung · 2026-08-27T15:51:18Z

@bors r-

rust-bors · 2026-08-27T15:51:26Z

This pull request was unapproved.

This PR was contained in a rollup (#161874), which was unapproved.

View changes since this unapproval

rust-bors · 2026-08-27T16:43:15Z

💔 Test for 052f00a failed: CI. Failed job:

try - aarch64-gnu (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-08-27T16:43:17Z

The job aarch64-gnu failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)


---- [ui] tests/ui/scalable-vectors/debuginfo-no-opt-llvm-ice.rs stdout ----

error: test compilation failed although it shouldn't!
status: signal: 6 (SIGABRT) (core dumped)
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/scalable-vectors/debuginfo-no-opt-llvm-ice.rs" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/scalable-vectors/debuginfo-no-opt-llvm-ice" "-Znext-solver=coherence" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "--edition=2021" "-Ctarget-feature=+sve,+sve2" "-Copt-level=0" "-g"
stdout: none
--- stderr -------------------------------
rustc: /checkout/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:247: const T& llvm::ArrayRef<T>::operator[](size_t) const [with T = llvm::Type*; size_t = long unsigned int]: Assertion `Index < Length && "Invalid index!"' failed.
------------------------------------------

---- [ui] tests/ui/scalable-vectors/debuginfo-no-opt-llvm-ice.rs stdout end ----
---- [ui] tests/ui/scalable-vectors/transmute.rs stdout ----

error: test compilation failed although it shouldn't!
status: signal: 6 (SIGABRT) (core dumped)
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/scalable-vectors/transmute.rs" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/scalable-vectors/transmute" "-Znext-solver=coherence" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "-Copt-level=3"
stdout: none
--- stderr -------------------------------
rustc: /checkout/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:247: const T& llvm::ArrayRef<T>::operator[](size_t) const [with T = llvm::Type*; size_t = long unsigned int]: Assertion `Index < Length && "Invalid index!"' failed.
------------------------------------------

---- [ui] tests/ui/scalable-vectors/transmute.rs stdout end ----
---- [ui] tests/ui/scalable-vectors/transparent-wrappers.rs stdout ----

error: test compilation failed although it shouldn't!
status: signal: 6 (SIGABRT) (core dumped)
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/scalable-vectors/transparent-wrappers.rs" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/scalable-vectors/transparent-wrappers" "-Znext-solver=coherence" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "--edition=2021" "--emit=obj" "-Ctarget-feature=+sve"
stdout: none
--- stderr -------------------------------
rustc: /checkout/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:247: const T& llvm::ArrayRef<T>::operator[](size_t) const [with T = llvm::Type*; size_t = long unsigned int]: Assertion `Index < Length && "Invalid index!"' failed.
------------------------------------------

---- [ui] tests/ui/scalable-vectors/transparent-wrappers.rs stdout end ----

failures:

rust-bors · 2026-08-28T05:26:33Z

☔ The latest upstream changes (presumably #161398) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

rustbot assigned dianqk May 30, 2026

This comment has been minimized.

Sign in to view

sayantn force-pushed the overloaded-intrinsics branch 2 times, most recently from a399a07 to c55c137 Compare May 30, 2026 13:05

sayantn mentioned this pull request May 31, 2026

Correct some wrong uses of LLVM intrinsics rust-lang/stdarch#2144

Merged

This comment has been minimized.

Sign in to view

sayantn added 2 commits July 9, 2026 01:53

Codegen overloaded LLVM intrinsics using their name

1ac3d44

Remove all uses of typed pointers

36e3bbc

sayantn force-pushed the overloaded-intrinsics branch from c55c137 to 36e3bbc Compare July 8, 2026 20:34

dianqk approved these changes Aug 27, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2026

JonathanBrouwer mentioned this pull request Aug 27, 2026

Rollup of 4 pull requests #161854

Closed

matthiaskrgr mentioned this pull request Aug 27, 2026

Rollup of 4 pull requests #161863

Closed

matthiaskrgr mentioned this pull request Aug 27, 2026

Rollup of 5 pull requests #161869

Closed

matthiaskrgr mentioned this pull request Aug 27, 2026

Rollup of 7 pull requests #161871

Closed

RalfJung reviewed Aug 27, 2026

View reviewed changes

matthiaskrgr mentioned this pull request Aug 27, 2026

Rollup of 12 pull requests #161874

Closed

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Aug 27, 2026

Auto merge of #157145 - sayantn:overloaded-intrinsics, r=<try>

052f00a

Codegen Overloaded LLVM intrinsics based on their name try-job: aarch64-gnu

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 27, 2026

Uh oh!

Uh oh!

Conversation

sayantn commented May 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented May 30, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Jul 8, 2026

Uh oh!

apiraino commented Aug 19, 2026

Uh oh!

dianqk commented Aug 24, 2026

Uh oh!

dianqk left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianqk commented Aug 27, 2026

Uh oh!

rust-bors Bot commented Aug 27, 2026

Uh oh!

RalfJung Aug 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikic Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianqk Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikic Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 30, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

RalfJung commented Aug 27, 2026

Uh oh!

rust-bors Bot commented Aug 27, 2026

Uh oh!

rust-bors Bot commented Aug 27, 2026

Uh oh!

rust-log-analyzer commented Aug 27, 2026

Uh oh!

rust-bors Bot commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

sayantn commented May 30, 2026 •

edited by rustbot

Loading

dianqk left a comment •

edited by rustbot

Loading

RalfJung Aug 27, 2026 •

edited by rustbot

Loading

RalfJung Aug 27, 2026 •

edited

Loading

RalfJung Aug 30, 2026 •

edited

Loading

RalfJung commented Aug 27, 2026 •

edited

Loading