draft: arch: Add Hexagon HVX instructions #1999

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.

crates/core_arch/src/hexagon/hvx.rs

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?

crates/core_arch/src/hexagon/hvx.rs

Replace print statements with assertions that verify the Gaussian 3x3 blur implementation against the Hexagon SDK reference algorithm. - Port exact SDK Gaussian3x3u8 implementation from: /opt/Hexagon_SDK/.../Examples/HVX/gaussian/src/gaussian.c - Verify specific output values [15, 16, 17, 18, 19, 20, 21, 22] for row 2, cols 1..9 with test pattern ((x + y*7) % 256) - Assert byte-averaging approximation exactly matches SDK reference - On Hexagon: verify HVX output matches both scalar approximation and SDK reference exactly

- Move regex compilations outside loops - Use Option::map and or_else instead of manual if-let chains - Use strip_prefix instead of manual starts_with + slice - Use !is_empty() instead of len() >= 1 - Combine consecutive str::replace calls

Updates cc crate to 1.2.55 which fixes macabi target triple handling for x86_64-apple-ios-macabi builds.

folkertdev · 2026-02-12T17:22:47Z

examples/gaussian.rs

+//!     qemu-hexagon -L <sysroot>/target/hexagon-unknown-linux-musl \
+//!         target/hexagon-unknown-linux-musl/debug/gaussian
+
+#![cfg_attr(target_arch = "hexagon", feature(stdarch_hexagon))]


you could use

#![target_arch = "hexagon"]

so that it applies to the module as a whole. Is there any particular reason not to do that, it seems like it would clean up a bunch of the conditionals.

While making this update I remembered that there's an outstanding compiler issue that I should fix so that the example can be at parity with the intrinsics in the C/C++ reference code.

I'll make a rustc PR for that one and revisit this after.

Opened rust-lang/rust#152552

I will put the HvxVectorPairs back into the gaussian.rs when that lands.

Add `#![cfg(target_arch = "hexagon")]` - Remove redundant #[cfg(target_arch = "hexagon")] from functions - Simplify import and constant cfg conditions - Remove non-Hexagon test code branch from main()

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

crates/core_arch/src/hexagon/hvx.rs Outdated Show resolved Hide resolved

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

androm3da added 2 commits February 12, 2026 07:33

arch: Add Hexagon HVX instructions

5c9f996

Switched to 64b and 128b crate definitions

1157c4d

androm3da force-pushed the main branch from 5583914 to ef26545 Compare February 12, 2026 13:33

androm3da added 3 commits February 12, 2026 07:47

examples: Fix rustfmt formatting in gaussian.rs

c1ed719

stdarch-gen-hexagon: Remove unused module_name method

13a192b

stdarch-gen-hexagon: Fix clippy warnings

66391da

- Move regex compilations outside loops - Use Option::map and or_else instead of manual if-let chains - Use strip_prefix instead of manual starts_with + slice - Use !is_empty() instead of len() >= 1 - Combine consecutive str::replace calls

androm3da force-pushed the main branch from f6cd941 to 66391da Compare February 12, 2026 15:34

Update Cargo.lock

1c1b1cf

Updates cc crate to 1.2.55 which fixes macabi target triple handling for x86_64-apple-ios-macabi builds.

folkertdev reviewed Feb 12, 2026

View reviewed changes

examples: Simplify gaussian.rs with cfg gate

046bb76

Add `#![cfg(target_arch = "hexagon")]` - Remove redundant #[cfg(target_arch = "hexagon")] from functions - Simplify import and constant cfg conditions - Remove non-Hexagon test code branch from main()

draft: arch: Add Hexagon HVX instructions #1999

Are you sure you want to change the base?

draft: arch: Add Hexagon HVX instructions #1999

Uh oh!

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!

folkertdev Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

folkertdev Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

androm3da Jan 22, 2026

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!

Uh oh!

folkertdev Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

androm3da Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

androm3da Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

androm3da Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

androm3da commented Jan 22, 2026 •

edited

Loading