Skip to content

Add 64-bit integer vectors and operations on them#253

Open
Shnatsel wants to merge 18 commits into
linebender:mainfrom
Shnatsel:64-bit-ints
Open

Add 64-bit integer vectors and operations on them#253
Shnatsel wants to merge 18 commits into
linebender:mainfrom
Shnatsel:64-bit-ints

Conversation

@Shnatsel

@Shnatsel Shnatsel commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

There are two unrelated changes:

  1. The documentation on load/store_interleaved_128 is fixed to match the implementation, which in turn mirrors the NEON intrinsics
  2. Some generic fallback methods are refactored to match the fallback's fully unrolled style as opposed to array::from_fn() calls

Supersedes #97

@Shnatsel

Copy link
Copy Markdown
Contributor Author

The documentation for load/store_interleaved_128 was misleading. Both formulations are valid for 32-bit elements but the 8- and 16-bit elements already behaved differently, following the NEON vld4/vst4 semantics rather than our documented semantics. This misled me into generalizing the op to 64-bit numbers incorrectly.

I've changed the implementation back to vld4/vst4 semantics in subsequent commits and updated documentation.

Comment thread fearless_simd_gen/src/generic.rs Outdated
Add i64/u64 vector types and operations across the generated SIMD backends, with focused int64 coverage and optimized interleaved load/store paths where available.
@LaurenzV

Copy link
Copy Markdown
Collaborator

I'm curious, do you think this will overall impact the compile time for the crate a lot, even if none of the 64-bit stuff is used? Have you done any measurements?

@Shnatsel

Copy link
Copy Markdown
Contributor Author

It really shouldn't. This is all generic code, so it is not actually instantiated and doesn't turn into MIR or LLVM IR until something actually calls it.

The downside of generics is that if we call the same function 5 times you get 5 different instantiations of it so 5x the IR for LLVM to chew through, but in our case we want all the intrinsics inlined anyway so this is unavoidable, generics or not.

@Shnatsel

Copy link
Copy Markdown
Contributor Author

Marking this as draft until it's updated to latest main. Some refactoring should also be possible now that the SSE2 PR has laid the groundwork for nicer scalar fallback.

@Shnatsel
Shnatsel marked this pull request as draft July 18, 2026 14:36
Comment on lines +1358 to +1364
if vec_ty.scalar_bits == 64
&& matches!(vec_ty.scalar, ScalarType::Int | ScalarType::Unsigned)
&& method != "simd_eq"
{
return fallback_method(op, vec_ty);
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like that this fires only when it's not AVX-512 but this is not explicitly under an else or a non-AVX-512 branch. I want to refactor all the early returns out of the generator, but that's best left to a follow-up PR, I don't want to cram even more unrelated changes into this one.

@Shnatsel

Copy link
Copy Markdown
Contributor Author

This should now be ready for review.

@Shnatsel
Shnatsel marked this pull request as ready for review July 18, 2026 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants