Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AArch64] NEON, SVE2 and SME2 instruction support with tests #439

Open
wants to merge 71 commits into
base: dev
Choose a base branch
from

Conversation

FinnWilkinson
Copy link
Contributor

This PR adds a wide range of different NEON, SVE2, SME2 instructions with regressions tests. These facilitate a subset of some internal SME-based GEMM and GEMV codes.

There is some BF16 prototypical instruction support which by default is disabled (using a new build option and an if statement in each appropriate switch statement case) due to some usage of __bf16 which is not compiler agnostic, some hacky usage of memcpy to re-interpret uint16_t, and a lack of regression tests for the BF16 instructions in question.

These BF16 instructions can be enabled through a new CMake option -DSIMENG_ENABLE_BF16=ON. I have deliberately not included this in the documentation given the possible instibility of the BF16 implementation and to keep it for (mainly) internal usage only.

This branch is based on sme2-support (PR #429 ) and so should be merged after this brnch has been merged into dev.

Some SM2 instructions which use multi-vector operands can be non-trivial to read or understand. Please ask for clarification and suggest any additional comments that may help future understanding.

@FinnWilkinson FinnWilkinson added the enhancement New feature or request label Nov 4, 2024
@FinnWilkinson FinnWilkinson self-assigned this Nov 4, 2024
@FinnWilkinson FinnWilkinson changed the base branch from dev to sme2-support November 4, 2024 18:12
@FinnWilkinson FinnWilkinson force-pushed the sme-loops-support branch 2 times, most recently from f9a759f to f2b86fa Compare November 7, 2024 19:58
Copy link
Contributor

@ABenC377 ABenC377 left a comment

Choose a reason for hiding this comment

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

Only a few comments

CMakeLists.txt Show resolved Hide resolved
src/include/simeng/arch/aarch64/Instruction.hh Outdated Show resolved Hide resolved
src/include/simeng/arch/aarch64/helpers/sve.hh Outdated Show resolved Hide resolved
@@ -548,7 +549,7 @@ void Instruction::decode() {
} else if (metadata_.operands[0].is_vreg) {
setInstructionType(InsnType::isVectorData);
} else if ((metadata_.operands[0].reg >= AARCH64_REG_ZAB0 &&
metadata_.operands[0].reg <= AARCH64_REG_ZT0) ||
metadata_.operands[0].reg < AARCH64_REG_ZT0) ||
Copy link
Contributor

Choose a reason for hiding this comment

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

Can ZT0 be used in a SVE context?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ZT0 is enabled / disabled in the same way as Z0 but has a fixed width of 512-bits, with the logic for detecting whether a ZT0 related instruction can / can't be executed done in instruction_execute as with all other SME instructions.

Regarding where in a core/implementation ZT0 based instructions are executed, there is no fixed rule in the spec as far as I can tell.... Given its fixed width, to me it seems more SVE-like than SME hence the grouping seen here. And given we don't have co-processor SME support, theres no offload / seperate chip logic to come into play yet

// zm.h
// SME
// BF16 -- EXPERIMENTAL
if (std::string(SIMENG_ENABLE_BF16) == "OFF") return executionNYI();
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this would be better implemented through a preprocessor directive for the entire case

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

@@ -190,6 +190,24 @@ inline std::vector<std::tuple<CoreType, std::string>> genCoreTypeSVLPairs(
checkMatrixRegisterCol<type>(tag, index, __VA_ARGS__); \
}

/** Check each element of the Lookup Table register ZT0 against expected values.
*
* The `tag` argument is the register index (must be 0), and the `type` argument
Copy link
Contributor

Choose a reason for hiding this comment

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

If tag must always be 0, then why not hardcode it as such?

@@ -151,7 +151,6 @@ TEST_P(Exception, unmapped_sys_reg) {
EXPECT_EQ(stdout_.substr(0, strlen(err)), err);
}

#if SIMENG_LLVM_VERSION >= 14
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this in response to the SVE vs SVE2 identification issue or something else? I feel like we can keep this sort of checking in

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes - in response to the SVE / SVE2 and SME / SME2 checks (i.e. it is not trivial). This one can stay though, yes

@@ -486,6 +520,66 @@ void Instruction::execute() {
branchAddress_ = instructionAddress_ + metadata_.operands[0].imm;
break;
}
case Opcode::AArch64_BF16DOTlanev8bf16: { // bfdot vd.4s, vn.8h,
Copy link
Contributor

Choose a reason for hiding this comment

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

Do the bf16 instructions have test cases?

Copy link
Contributor Author

@FinnWilkinson FinnWilkinson Dec 16, 2024

Choose a reason for hiding this comment

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

No, I've kept them as experimental implementations and undocumented, including how to enable them. You would need to look through the sourcecode and CMake files to know it is there

@@ -486,6 +520,66 @@ void Instruction::execute() {
branchAddress_ = instructionAddress_ + metadata_.operands[0].imm;
break;
}
case Opcode::AArch64_BF16DOTlanev8bf16: { // bfdot vd.4s, vn.8h,
Copy link
Contributor

Choose a reason for hiding this comment

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

Do the bf16 instructions have test cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, I've kept them as experimental implementations and undocumented, including how to enable them. You would need to look through the sourcecode and CMake files to know it is there

@@ -283,6 +283,43 @@ enum class InsnType : uint32_t {
isBranch = 1 << 14
};

/** Predefined shift values for converting pred-as-counter to pred-as-mask. */
const uint64_t predCountShiftVals[9] = {0, 1, 2, 0, 3, 0, 0, 0, 4};
Copy link
Contributor

Choose a reason for hiding this comment

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

Unless I've missed something, this is used in one location. Why is the data defined as a variable outside of all function scopes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed as can calculate it automatically

endif()
if (${LLVM_PACKAGE_VERSION} VERSION_LESS "18.0")
message(STATUS "LLVM version does not support AArch64 extensions SME2. These test suites will be skipped.")
message(STATUS "LLVM version does not support AArch64 extensions SVE2, SVE2.1, SME, or SME2. Related tests will fail.")
Copy link
Contributor

Choose a reason for hiding this comment

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

Why can't we place preprocessor directives around the SME tests? I though it was just a SVE vs SVE2 problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is a similar problem with SME and SME2

ABenC377
ABenC377 previously approved these changes Dec 17, 2024
@FinnWilkinson FinnWilkinson force-pushed the sme-loops-support branch 2 times, most recently from 393dd26 to b027f73 Compare December 18, 2024 15:07
@FinnWilkinson FinnWilkinson changed the base branch from sme2-support to dev December 20, 2024 10:01
@FinnWilkinson FinnWilkinson dismissed ABenC377’s stale review December 20, 2024 10:01

The base branch was changed.

…ged address generation logic for ST2W and ST4W.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Changes Requested
Development

Successfully merging this pull request may close these issues.

3 participants