draft: arch: Add Hexagon HVX instructions by androm3da · Pull Request #1999 · rust-lang/stdarch

androm3da · 2026-01-22T20:05:27Z

Note: this depends on #151500
Tracking issue #151523

rustbot · 2026-01-22T20:05:32Z

rustbot has assigned @folkertdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

androm3da · 2026-01-22T20:06:33Z

cc @folkertdev

I'm still working out how to get the CI to execute this, I should be able to make it work with qemu-hexagon linux-userspace emu, which is hopefully similar to how other targets do it.

folkertdev · 2026-01-22T20:10:31Z

Yeah I figured that would be a bit of a challenge, so more efficient to do that in parallel.

folkertdev

General note: this looks largely machine-generated? We already have stdarch-gen-loongarch and stdarch-gen-arm, so it's possible to check that in.

androm3da · 2026-01-22T20:15:31Z

General note: this looks largely machine-generated? We already have stdarch-gen-loongarch and stdarch-gen-arm, so it's possible to check that in.

Ok, will add the generation script here too.

folkertdev · 2026-01-22T20:18:19Z

crates/core_arch/src/hexagon/hvx.rs

+#[inline]
+#[cfg_attr(target_arch = "hexagon", target_feature(enable = "hvxv60"))]
+#[unstable(feature = "stdarch_hexagon", issue = "none")]


For most targets we like adding a test that the intrinsic does in fact produce the expected instruction, e.g.

// avx512bw #[cfg_attr(test, assert_instr(vpabsw))] // wasm #[cfg_attr(test, assert_instr(v128.load8x8_s))]

especially if you are machine-generating these that should hopefully be straightforward.

folkertdev · 2026-01-22T20:20:13Z

crates/core_arch/src/hexagon/hvx.rs

+/// Execution Slots: SLOT0123
+#[inline]
+#[cfg_attr(target_arch = "hexagon", target_feature(enable = "hvxv60"))]
+#[unstable(feature = "stdarch_hexagon", issue = "none")]


before we merge this you can create a tracking issue in the main repo, see e.g. rust-lang/rust#117427

folkertdev · 2026-01-22T20:26:45Z

crates/core_arch/src/hexagon/hvx.rs

+#[cfg_attr(target_arch = "hexagon", target_feature(enable = "hvxv60"))]
+#[unstable(feature = "stdarch_hexagon", issue = "none")]
+pub unsafe fn q6_v_vxor_vv(vu: HvxVector, vv: HvxVector) -> HvxVector {
+    vxor(vu, vv)


it's a bit hard to deduce from the names, but I'm assuming this corresponds to simd_xor

https://doc.rust-lang.org/nightly/std/intrinsics/simd/fn.simd_xor.html

We generally prefer using functions from crate::intrinsics::simd (starting with crate is deliberate, using core:: can cause trouble when bootstrapping). It's much easier for us to then know what a function does, and as a bonus Miri will be able to run the intrinsics too.

When using intrinsics::simd it is even more important to check that these functions emit the right instruction. Sometimes additional optimizations are needed in LLVM to make that work.

I think it's fine to do this gradually, but for some of the simpler operations it's probably possible to do it from the start.

for some of the simpler operations it's probably possible to do it from the start.

Sure - can do!

androm3da · 2026-01-22T21:32:59Z

General note: this looks largely machine-generated? We already have stdarch-gen-loongarch and stdarch-gen-arm, so it's possible to check that in.

Ok, will add the generation script here too.

Ah - okay, I see that these are different from what I've implemented. I have a python script that takes a C/C++ toolchain header file as a source-of-truth. So @folkertdev should I implement that instead as a crate that parses a yaml file?

folkertdev · 2026-01-22T21:40:19Z

The input is up to you, arm uses an elaborate yaml setup, loongarch uses a simpler text format derived from header files. A custom format makes it easier to override an implementation with the intrinsics::simd one. Maybe you can use some sort of special comment to include that in the header?

We would prefer having rust over python though, hopefully that is straightforward to port?

androm3da · 2026-01-22T21:44:42Z

We would prefer having rust over python though, hopefully that is straightforward to port?

It is, yeah.

Maybe you can use some sort of special comment to include that in the header?

Sorry, not sure if I follow. Add comments in the C header file used as an input? Or ... ?

folkertdev · 2026-01-22T21:57:39Z

Taking q6_v_vxor_vv as an example, you'd need some way to indicate that instead of following the normal path picking some LLVM intrinsic, it should use simd_xor. For arm we update its yaml file and re-run the generator. loongarch does not yet use intrinsics::simd, so it also needs to figure this out.

Maybe this was unclear, but currently the workflow is that we don't manually update the generated rust code, but instead modify the inputs to the generator and re-run it. That is convenient when new instructions are added, and it is usually simpler to edit the input than the output.

Anyhow, none of that is official, that's just what we have. So if there are good reasons to deviate from it that is something we can discuss.

androm3da · 2026-01-22T22:13:31Z

some way to indicate that instead of following the normal path picking some LLVM intrinsic

Ah okay I gotcha now. So my plan was to just include a hardcoded list in the script/rust program of the intrinsics that do map to the architecture-independent ones and the exceptions get lowered to the architecture-specific ones.

folkertdev · 2026-01-22T22:14:43Z

Cool, that should work

folkertdev · 2026-01-26T10:19:34Z

doing a quick close/open here to see what CI says now that the features are available

folkertdev · 2026-01-26T10:24:25Z

hmm

    Compiling panic_abort v0.0.0 (/rust/lib/rustlib/src/rust/library/panic_abort)
   Compiling cfg-if v1.0.4
   Compiling rustc-demangle v0.1.26
   Compiling unwind v0.0.0 (/rust/lib/rustlib/src/rust/library/unwind)
   Compiling rustc-literal-escaper v0.0.7
error: symbol 'fma' is already defined

error: could not compile `compiler_builtins` (lib) due to 1 previous error

is there some issue with hexagon in compiler_builtins? Maybe it just wasn´t considered in some cfg construction?

androm3da · 2026-01-26T14:49:26Z

is there some issue with hexagon in compiler_builtins? Maybe it just wasn´t considered in some cfg construction?

This fma issue was a bug in compiler_builtins and I've since fixed it - or so I thought.

I have been noodling over the design of this PR and have several local changes. None of them were intended to address the fma symbol issue but I'll push those and then I'll work on addressing that issue.

folkertdev · 2026-01-26T14:55:37Z

Weird. We're using latest nightly here, maybe something was not synchronized?

androm3da · 2026-01-26T15:46:57Z

Weird. We're using latest nightly here, maybe something was not synchronized?

Yeah, it's not obvious to me yet. This was fixed a while ago (rust-lang/compiler-builtins#682). I'll need to spend some time trying to reproduce it and maybe something just needs to update an explicit compiler-builtins dependency to a newer release.

folkertdev · 2026-01-26T16:00:49Z

Oh, yes, it's building compiler_builtins v0.1.160, which is the latest, but it's 8 months old. I'm not sure (yet) why that dependency is built though, cargo tree does not show it.

androm3da · 2026-01-26T16:04:50Z

Oh, yes, it's building compiler_builtins v0.1.160, which is the latest, but it's 8 months old. I'm not sure (yet) why that dependency is built though, cargo tree does not show it.

compiler_builtins-v0.1.160 has that fix, so I'm not sure if that's the issue.

tgross35 · 2026-01-26T19:33:02Z

Oh, yes, it's building compiler_builtins v0.1.160, which is the latest, but it's 8 months old. I'm not sure (yet) why that dependency is built though, cargo tree does not show it.

Note that we don't use crates.io c-b anymore, it should only ever be coming via the submodule which is actively updated. Think this will still technically show as 0.1.160 though.

folkertdev

Any luck with figuring out why the build fails?

folkertdev · 2026-01-30T21:02:59Z

crates/core_arch/src/hexagon/hvx.rs

+//! This implementation targets 128-byte mode by default. To change the vector
+//! length mode, use the appropriate target feature when compiling:
+//! - For 128-byte mode: `-C target-feature=+hvx-length128b`
+//! - For 64-byte mode: `-C target-feature=+hvx-length64b`


This doesn't work unless you also pass -Zbuild-std. Normally when you compile a program, you're using a pre-built std that uses the default configuration.

On other targets, the types and intrinsics are actually available unconditionally. It is just UB to call the intrinsics that need a target feature when that feature is not present.

e.g. on x86_64 the namespacing is in the name _mm vs _mm256 etc. Here maybe we should namespace with a module, so have a 64 and 128-byte module, both of which are available unconditionally, but of course need the target feature to actually use the intrinsics.

but maybe there are additional details that I'm missing?

Any luck with figuring out why the build fails?

Sorry, I haven't spent enough time looking into this in the last few days. I'll dig in and sort it out.

This doesn't work unless you also pass -Zbuild-std. Normally when you compile a program, you're using a pre-built std that uses the default configuration.

Not for hexagon, though. Since its artifacts aren't included, -Zbuild-std is a fairly convenient way to resolve that dependency.

maybe there are additional details that I'm missing?

Yeah - it's kinda inconvenient that the ISA was designed this way. But it was. The semantics of the instructions change based on the system mode. Either the system is in 64-byte mode, or it's in 128-byte mode. The register size depends on the mode. In practice, modern parts only support 128-byte mode. But several DSPs were made with only 64-byte mode, and several with support for both modes. So we're stuck with the LLVM backend looking and behaving the way it does in order to target all the various Hexagon HVX coprocs out there. You'll see C/C++ code handle these intrinsics and their types by considering the __HVX_LENGTH__ preprocessor definition that's emitted. If there's a better way to handle it for rust than how it's being done here, I'm happy to consider another approach.

I'll start by documenting the above details in the crate's user documentation so that it's less confusing for all involved.

Hmm but now re-reading what you've said I think I misunderstood your suggestion.

Here maybe we should namespace with a module, so have a 64 and 128-byte module, both of which are available unconditionally, but of course need the target feature to actually use the intrinsics.

Yeah sorry for the confusion -- this should be do-able.

Rebased and squashed the commits for this PR, leaving the 64b/128b crate split as its own commit to make it easier to see what changed from the previous commit set.

Any luck with figuring out why the build fails?

Tsk! rust-lang/compiler-builtins#1066 -- dunno why I thought the symbol would be private but that was the issue.

rustbot assigned folkertdev Jan 22, 2026

folkertdev reviewed Jan 22, 2026

View reviewed changes

folkertdev mentioned this pull request Jan 23, 2026

hexagon: Add HVX target features rust-lang/rust#151500

Merged

androm3da mentioned this pull request Jan 23, 2026

Tracking Issue for Hexagon arch intrinsics rust-lang/rust#151523

Open

10 tasks

folkertdev closed this Jan 26, 2026

folkertdev reopened this Jan 26, 2026

androm3da mentioned this pull request Jan 27, 2026

add support for Hexagon HVX rust-lang/portable-simd#500

Closed

folkertdev reviewed Jan 30, 2026

View reviewed changes

androm3da added 2 commits January 30, 2026 20:36

arch: Add Hexagon HVX instructions

8295d82

Switched to 64b and 128b crate definitions

5583914

androm3da force-pushed the main branch from 0da4009 to 5583914 Compare January 31, 2026 02:36

Conversation

androm3da commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 22, 2026

Uh oh!

androm3da commented Jan 22, 2026

Uh oh!

folkertdev commented Jan 22, 2026

Uh oh!

folkertdev left a comment

Choose a reason for hiding this comment

Uh oh!

androm3da commented Jan 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

androm3da commented Jan 22, 2026

Uh oh!

folkertdev commented Jan 22, 2026

Uh oh!

androm3da commented Jan 22, 2026

Uh oh!

folkertdev commented Jan 22, 2026

Uh oh!

androm3da commented Jan 22, 2026

Uh oh!

folkertdev commented Jan 22, 2026

Uh oh!

folkertdev commented Jan 26, 2026

Uh oh!

folkertdev commented Jan 26, 2026

Uh oh!

androm3da commented Jan 26, 2026

Uh oh!

folkertdev commented Jan 26, 2026

Uh oh!

androm3da commented Jan 26, 2026

Uh oh!

folkertdev commented Jan 26, 2026

Uh oh!

androm3da commented Jan 26, 2026

Uh oh!

tgross35 commented Jan 26, 2026

Uh oh!

folkertdev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

androm3da commented Jan 22, 2026 •

edited

Loading