Skip to content

Enable host-native architecture tuning for GNU/Clang builds (fixes #209) - #257

Open
manishpaulish wants to merge 3 commits into
hpcgarage:spatter-develfrom
manishpaulish:fix/209-native-arch
Open

manishpaulish wants to merge 3 commits into
hpcgarage:spatter-develfrom
manishpaulish:fix/209-native-arch

Conversation

@manishpaulish

Copy link
Copy Markdown

Overview

Spatter is a memory microbenchmark, so its kernels need to be compiled for the ISA of the machine being measured. The Intel-compiler path already does this via -xHost, but the GNU and Clang paths added no architecture flag at all, so the compiler targeted the baseline x86-64 (SSE2) ISA and never emitted AVX/AVX2/AVX-512 in the gather/scatter kernels. This is the behavior reported in #209, where -mavx had to be passed by hand to turn movsd into vmovsd.

Fixes #209.

✨ Change Description/Rationale

  • cmake/CompilerType.cmake now adds the GNU/Clang equivalent of -xHost:
    • SPATTER_ENABLE_NATIVE_ARCH (default ON) adds -march=native, falling back to -mcpu=native on toolchains where -march=native is unsupported (e.g. Apple arm64). Detected with check_cxx_compiler_flag.
    • SPATTER_ARCH_FLAGS lets you pin an explicit target instead, e.g. -DSPATTER_ARCH_FLAGS="-march=sapphirerapids". It takes precedence over native detection.
    • Native tuning is skipped automatically when cross-compiling (CMAKE_CROSSCOMPILING), and can be turned off with -DSPATTER_ENABLE_NATIVE_ARCH=OFF for portable/reproducible binaries.
  • Build.md documents both options in the CMake Options table.

The design mirrors the existing Intel -xHost handling and keeps the default "fast on the machine you're benchmarking," while giving CI and packagers an explicit escape hatch for reproducible builds.

Testing

  • Default build reports Enabling host-native architecture tuning: -march=native, and the flag appears on the kernel compile line (CXX_FLAGS = -march=native -O3 -DNDEBUG ... -fopenmp).
  • Override (-DSPATTER_ARCH_FLAGS=...) is used verbatim and native detection is skipped.
  • Disabled (-DSPATTER_ENABLE_NATIVE_ARCH=OFF) reproduces the previous baseline flags exactly — no behavior change for anyone who wants it off.
  • Full cmake --build succeeds and the resulting binary runs correctly (./spatter -pUNIFORM:8:1 -l$((2**20)) gives expected bandwidth output).

To confirm the AVX codegen change on x86_64 (per #209):

objdump --disassemble=_ZN7Spatter13ConfigurationINS_6OpenMPEE7scatterEbm._omp_fn.0 ./build_openmp/spatter | grep -c vmov
# nonzero with the fix; 0 before

Note: I verified the CMake logic, flag propagation, and a clean build/run locally on an aarch64 host (where the same "no arch flag" gap exists, and the fix selects -mcpu=native). The x86 movsd→vmovsd change is the one documented in #209.

Only the Intel path set a host-arch flag (-xHost); GNU/Clang got none, so the build targeted baseline x86-64 and never emitted AVX in the gather/scatter kernels. Add SPATTER_ENABLE_NATIVE_ARCH (default ON: -march=native, or -mcpu=native fallback) and SPATTER_ARCH_FLAGS to override; skipped when cross-compiling.

Signed-off-by: MANISH PAUL <manishpaul.24@kgpian.iitkgp.ac.in>
Signed-off-by: MANISH PAUL <manishpaul.24@kgpian.iitkgp.ac.in>
Signed-off-by: MANISH PAUL <manishpaul.24@kgpian.iitkgp.ac.in>
@manishpaulish

Copy link
Copy Markdown
Author

Hi @jyoung3131, friendly ping on this one. It's a small, self-contained change: it adds the GNU/Clang equivalent of the Intel -xHost path so the gather/scatter kernels are actually built for the host ISA (fixes #209), and it merges cleanly.

Since I'm a first-time contributor, the CI workflows are still waiting on maintainer approval. Would you or another maintainer be able to approve them so the checks can run? Happy to adjust anything, or split the doc change out, if that's easier to review. Thanks!

@jyoung3131
jyoung3131 requested review from jyoung3131 and plavin August 3, 2026 20:41
@manishpaulish

Copy link
Copy Markdown
Author

Quick follow-up: the CI workflows on this PR are still showing "awaiting approval", so there are no check results for @jyoung3131 or @plavin to review against. If one of you is able to approve the workflow run, the checks should give you a clearer signal on whether this is safe to merge.

No rush on the review itself. Also happy to split the Build.md doc change into a separate PR if that would make this easier to evaluate.

@jyoung3131

Copy link
Copy Markdown
Contributor

Hi Manish - thank you for your contribution. We will review and get back to you in the next week or so as folks are currently on on travel and vacation.

This branch has not been deployed

No deployments
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