Simplify vectorization guidelines and add a vectorization skill

[tannergooding]

The general SIMD and hardware-intrinsics guidance now lives in the official docs, which were recently rewritten in dotnet/docs#54834. Our in-repo docs/coding-guidelines/vectorization-guidelines.md had become largely duplicative and out of sync, so this trims it down to defer to the official article and keep only the dotnet/runtime-specific nuance:

• The BoundedMemory test helper for access-violation testing (with a repo-relative link and a short usage example).
• The real LastIndexOf GC-hole case study (Vectorize {Last}IndexOf{Any} and {Last}IndexOfAnyExcept without code duplication #73768 / fix Fixing SpanHelpers.LastIndexOfAnyValueType to no longer create out of bounds GC refs #75857) behind the "prefer the element-offset overloads" rule.
• The Switch from direct intrinsics usage to Vector/Vector64/Vector128/Vector256 #64451 catalogue of real vectorized implementations to learn from.

The lane-crossing worked example that the official rewrite dropped is being restored upstream in dotnet/docs#54840 rather than kept here, since it''s general teaching content and belongs where it stays in sync.

---

Also adds a vectorization skill covering both authoring and reviewing SIMD code. Vectorization is a cross-cutting domain rather than a folder, so a task-triggered skill fits better than a file-scoped .instructions.md. The skill defers to the official docs and carries the same repo-specific nuance (prefer the span/LoadUnsafe element-offset overloads, BoundedMemory AV testing, the acceleration-toggle env vars, char/bool reinterpretation, and benchmarking before committing complexity), plus authoring/testing/review checklists. copilot-instructions.md gets a one-line nudge toward it, matching the existing code-review/performance-benchmark pattern.

Note

This PR description was drafted by GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
15 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates dotnet/runtime’s SIMD/vectorization guidance by shrinking the in-repo guidelines to runtime-specific nuance (and deferring general guidance to official Learn docs), and adds a new task-triggered vectorization skill to guide authoring/review of SIMD/hardware-intrinsics changes.

Changes:

• Replaces the large in-repo vectorization guideline document with a short “defer to official docs” version plus runtime-specific guidance (BoundedMemory AV testing, GC-hole case study, and links to real-world examples).
• Adds a new .github/skills/vectorization skill with SIMD authoring/testing/review checklists.
• Updates .github/copilot-instructions.md to nudge using the new vectorization skill for SIMD/hardware-intrinsics work.

Show a summary per file

File	Description
docs/coding-guidelines/vectorization-guidelines.md	Trims guidance to runtime-specific nuance and points to official SIMD docs; includes BoundedMemory + GC-hole case study + examples link.
.github/skills/vectorization/SKILL.md	Introduces a new skill with SIMD authoring/testing/review rules and checklists, deferring to official docs and capturing runtime-specific pitfalls.
.github/copilot-instructions.md	Adds a one-line instruction to use the vectorization skill when working with SIMD/hardware intrinsics.

Copilot's findings

Comments suppressed due to low confidence (3)

docs/coding-guidelines/vectorization-guidelines.md:36

• BoundedMemory.Allocate already populates the span with random data (per its remarks / implementation), so the extra Random.Shared.NextBytes(...) is redundant and makes the sample look like initialization is required.

    Random.Shared.NextBytes(MemoryMarshal.AsBytes(bounded.Span));

.github/skills/vectorization/SKILL.md:29

• "never cache them" is stronger than necessary and implies caching changes codegen. Since these are JIT-time constants, there's generally just no need to cache them for performance; a local var won't typically block constant folding.

2. **Start with `Vector128<T>`.** It's the common denominator accelerated on the broadest hardware, and
   you don't need `Vector256`/`Vector512` for a correct, portable implementation. Add wider widths and

.github/skills/vectorization/SKILL.md:76

• Like the in-repo guideline doc, this text implies the failure mode is a thrown AccessViolationException. The BoundedMemory docs describe it as causing an AV; depending on runtime / settings it may not be catchable.

  suite with no overrides, with `DOTNET_EnableAVX2=0` (disables `Vector256`), and with
  `DOTNET_EnableHWIntrinsic=0` (disables all intrinsics down to the software fallback). Build the
  affected library and run its test project per the build/test workflow in

• Files reviewed: 3/3 changed files
• Comments generated: 2

[Copilot]

Copilot's findings

Comments suppressed due to low confidence (2)

docs/coding-guidelines/vectorization-guidelines.md:22

• The BoundedMemory description implies it always provides a poison (MEM_NOACCESS) page and therefore reliably AVs on out-of-bounds reads. But BoundedMemory falls back to an unprotected allocator on some targets (e.g., Browser/WASI, and NETFRAMEWORK), where it won't reliably fault on OOB reads (see AllocateWithoutDataPopulationDefault / the Browser/WASI branch in AllocateWithoutDataPopulation). Please qualify this guidance so tests don’t over-rely on AV behavior on those platforms.

[`BoundedMemory`](/src/libraries/Common/tests/TestUtilities/System/Buffers/BoundedMemory.Creation.cs)
helper. It allocates a memory region immediately followed (or preceded) by a poison (`MEM_NOACCESS`)
page, so any out-of-bounds read throws an `AccessViolationException` during testing rather than silently
succeeding.

.github/skills/vectorization/SKILL.md:83

• This BoundedMemory bullet reads as if a no-access poison page is always present. However, BoundedMemory uses a fallback allocator on some targets (e.g., Browser/WASI, and NETFRAMEWORK) where page protection isn’t applied, so OOB reads won’t reliably throw AccessViolationException. Qualify the guidance accordingly.

- **Guard against out-of-bounds reads with `BoundedMemory`.**
  [`BoundedMemory.Allocate<T>(count)`](/src/libraries/Common/tests/TestUtilities/System/Buffers/BoundedMemory.Creation.cs)
  places a no-access page immediately after the buffer (use `PoisonPagePlacement.Before` for
  backwards-iterating algorithms), so any read past the end throws `AccessViolationException` during
  testing instead of silently succeeding. Always include lengths that aren't an exact multiple of the

• Files reviewed: 3/3 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

Comments suppressed due to low confidence (1)

.github/skills/vectorization/SKILL.md:28

• This overstates LINQ SIMD acceleration: Sum and Average have Vector<T> fast-paths when TryGetSpan succeeds, but Max/Min don't currently use SIMD in System.Linq. As written, this can mislead reviewers into assuming vectorization exists where it doesn't.

1. **Reach for the highest-level API that already does the job.** `Span<T>`/`string` methods,
   `TensorPrimitives`, and the tensor types already vectorize many operations. LINQ is often vectorized
   too — operators such as `Sum`, `Max`, `Min`, and `Average` accelerate when the source's underlying
   span can be extracted. Don't hand-roll what's already optimized and tested.

• Files reviewed: 3/3 changed files
• Comments generated: 2

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new