Skip to content

[Codegen][LLVM][Tests] Gate +v9a vscale_range expectation on LLVM version#19744

Merged
tqchen merged 1 commit into
apache:mainfrom
tlopex:fix-aarch64-v9a-vscale-range-expectation
Jun 12, 2026
Merged

[Codegen][LLVM][Tests] Gate +v9a vscale_range expectation on LLVM version#19744
tqchen merged 1 commit into
apache:mainfrom
tlopex:fix-aarch64-v9a-vscale-range-expectation

Conversation

@tlopex

@tlopex tlopex commented Jun 12, 2026

Copy link
Copy Markdown
Member

Since LLVM 19, SVE/SVE2 are optional extensions of Armv9.0-A (llvm/llvm-project#96007), so "+v9a" no longer implies "+sve" and CodeGenAArch64 does not add the vscale_range() function attribute. Gate the expectation in test_vscale_range_function_attribute on llvm_version_major() < 19 so the test passes on both older LLVM (15-17, as used in CI) and LLVM 19+.

…sion

Since LLVM 19, SVE/SVE2 are optional extensions of Armv9.0-A
(llvm/llvm-project#96007), so "+v9a" no longer implies "+sve" and
CodeGenAArch64 does not add the vscale_range() function attribute.
Gate the expectation in test_vscale_range_function_attribute on
llvm_version_major() < 19 so the test passes on both older LLVM
(15-17, as used in CI) and LLVM 19+.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request updates the AArch64 codegen tests to handle changes introduced in LLVM 19, where SVE/SVE2 are optional extensions of Armv9.0-A and '+v9a' no longer implies '+sve'. The test expectation for '+v9a' is updated to depend on the LLVM version being less than 19. There are no review comments, and I have no additional feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

@tqchen tqchen merged commit 6468df4 into apache:main Jun 12, 2026
10 checks passed
tlopex added a commit to tlopex/tvm that referenced this pull request Jun 13, 2026
tests/python/codegen/test_target_codegen_aarch64.py cross-compiles AArch64
SVE kernels and regex-matches the generated assembly for specific
instruction forms and counts. Several of those assertions encode the exact
code shape produced by the LLVM versions used in CI (15-17). On a TVM built
against LLVM 20 the tests fail, even though the emitted IR is correct (+sve
target-features and vscale_range(1,16) are present) -- the difference is
entirely inside LLVM's loop vectorizer / cost model, not in TVM's codegen.

This is the same class of issue as apache#19744 (which gated the +v9a
vscale_range expectation); that fix landed separately, and this change
covers the remaining test_muladd / test_eq / test_neq failures.

LLVM 20 behavior changes observed:
- Floating-point mul-add: LLVM 20 prefers a fixed-width NEON main loop
  (fmla v0.4s, ...) over a scalable SVE loop (mla z0.s, ...) for float /
  float16 fmuladd on generic AArch64 +sve, so the SVE mla/mad count drops
  to 0.
- Equality / inequality compares: LLVM <= 17 interleaves the scalable loop
  by two (2 SVE compares), while LLVM 20 emits a fixed-width NEON main loop
  with a single predicated SVE epilogue (1 SVE compare).

Changes (test-only, no codegen change):
- test_muladd: for LLVM >= 18 on float/float16, also accept the NEON
  ldr/ldp q* + fmla/fmls v*.Ns form in addition to the SVE form (a union,
  so whichever form a given LLVM emits keeps the assertion meaningful). The
  NEON regex requires a vector register (v0.4s), so a scalar tail fmadd s0
  cannot satisfy it.
- test_muladd: group the mad|mla alternation as (?:mad|mla)\t... . Without
  the group, a bare mad could match anywhere in the assembly (e.g. inside a
  scalar fmadd), inflating the count.
- test_eq / test_neq: relax the compare-count assertion from > 1 to > 0,
  since the interleave factor is an LLVM cost-model detail, not a codegen
  guarantee. CI's LLVM 15-17 still produces >= 1 SVE compare.

The assertions still require real AArch64 vector code -- they are not
weakened to vacuous checks, and the strict SVE path is unchanged for the
LLVM versions used in CI.
MasterJH5574 pushed a commit to MasterJH5574/tvm that referenced this pull request Jun 15, 2026
…sion (apache#19744)

Since LLVM 19, SVE/SVE2 are optional extensions of Armv9.0-A
(llvm/llvm-project#96007), so "+v9a" no longer implies "+sve" and
CodeGenAArch64 does not add the vscale_range() function attribute. Gate
the expectation in test_vscale_range_function_attribute on
llvm_version_major() < 19 so the test passes on both older LLVM (15-17,
as used in CI) and LLVM 19+.

(cherry picked from commit 6468df4)
MasterJH5574 pushed a commit to MasterJH5574/tvm that referenced this pull request Jun 15, 2026
…sion (apache#19744)

Since LLVM 19, SVE/SVE2 are optional extensions of Armv9.0-A
(llvm/llvm-project#96007), so "+v9a" no longer implies "+sve" and
CodeGenAArch64 does not add the vscale_range() function attribute. Gate
the expectation in test_vscale_range_function_attribute on
llvm_version_major() < 19 so the test passes on both older LLVM (15-17,
as used in CI) and LLVM 19+.

(cherry picked from commit 6468df4)
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.

3 participants