| # Working in the SIMD packages |
| |
| What these packages are, how the generators fit together, how to run them is in |
| [archsimd/_gen/README.md](archsimd/_gen/README.md). This file is only about not |
| burning your context window. |
| |
| ## Most of this tree, by volume, is generated — and some of it is enormous |
| |
| Generated files here are machine-uniform: hundreds to thousands of |
| near-identical stanzas, each a doc comment plus one declaration. |
| |
| ```go |
| // Add adds corresponding elements of two vectors. |
| // |
| // Asm: VPADDD, CPU Feature: AVX |
| func (x Int32x4) Add(y Int32x4) Int32x4 |
| ``` |
| |
| **Two or three stanzas tell you what the whole file would.** Reading one end to |
| end can consume a large fraction of your context and teach you nothing the |
| sample didn't. This stays true as the API grows: these files get longer, not |
| more varied. |
| |
| A file is generated if its first line says so: |
| |
| ```sh |
| head -1 <file> | grep 'Code generated' |
| ``` |
| |
| Don't rely on a remembered list of which files are big — measure: |
| |
| ```sh |
| find . -name '*.go' -size +50k -not -path '*/_gen/*' | xargs ls -lS |
| ``` |
| |
| `archsimd/ops_*.go`, `internal/simdref/simdref.go`, `internal/bridge/decls_*.go` |
| and the `simd_test` helpers are usually on that list. Treat it as a starting |
| point, not an inventory. |
| |
| ## Sample; don't read |
| |
| Anchor the pattern, ask for little context: |
| |
| ```sh |
| # the shape of one declaration, with its full doc comment |
| GOEXPERIMENT=simd go doc simd/archsimd.Int32x4.Add |
| |
| # which receivers carry an op — count first, list if you need to |
| grep -c '^func ([^)]*) Add(' archsimd/ops_amd64.go |
| ``` |
| |
| An unanchored `grep Add` also matches `AddSub`, `MulAdd`, `PairwiseAdd` and |
| every `// Asm:` line mentioning one. On a file of uniform stanzas, `-A5`/`-B5` |
| returns most of the file. |
| |
| ## Size tool output before you read it |
| |
| `specls` prints the expanded spec API. Its output is as large as the files it |
| describes, so use `-f` (a regexp) to narrow it, and anchor the pattern: |
| |
| ```sh |
| go run ./cmd/specls -f '^Add$' # one spec function |
| go run ./cmd/specls -f Add # every name containing "Add" — much larger |
| go run ./cmd/specls # the entire expanded API — very large |
| ``` |
| |
| Same caution for diffs. The README says to use `-diff` constantly, and that's |
| right — but regenerating a family can produce thousands of lines. Get the shape |
| first, then read what matters: |
| |
| ```sh |
| git diff --stat |
| go run . -tools <tool> -diff | wc -l |
| ``` |
| |
| ## Don't edit generated files |
| |
| Edit the generator input and regenerate. The first line of each generated file |
| names the inputs it was built from; use those to find what to edit, but |
| regenerate with `go generate` (see the README), not by re-running the command |
| in that line. Commit regenerated output in the same commit as the change that |
| caused it. |
| |
| ## If you were handed one spec transition task |
| |
| [archsimd/_gen/SPEC-TRANSITION.md](archsimd/_gen/SPEC-TRANSITION.md) is the |
| active plan. Read Part 2 (the rationale; tasks cite it by section number) and |
| your own task from Part 4. **Don't read Part 4 end to end** — it is every task |
| in the project, and you were given one. |