Add ARM SVE detection and SVE dispatch infrastructure and SVE-optimized paths for ColumnVector filter, unary arithmetic, and findExtreme#97473
Conversation
|
@chiranmoyf could you please take a look why the build in CI fails? |
|
@rienath, the error is from clang-tidy. The error is related to MULTITARGET_FUNCTION_X86_V4_V3_SVE. clang-tidy is flagging that FUNCTION_BODY is expanded multiple times in MULTITARGET_FUNCTION_X86_V4_V3_SVE. There are two solutions possible to this.
What do you think of these solutions? Do you have any other solution? |
|
@ajeyabsf thanks for taking a look. We expanded multiple times with x86 too, but looks like it didn't fire because our CI runner is on ARM. Let's add |
5c855c8 to
dc6b2aa
Compare
|
@rienath |
rienath
left a comment
There was a problem hiding this comment.
I've partially reviewed the PR and will continue once these comments are addressed. Some of them are questions / calls for discussion, so feel free to answer and ping me
dba3fb9 to
bd2e757
Compare
There was a problem hiding this comment.
The PR looks great! I've left a few nits, but we are almost done.
Regarding the pastila links with performance tests that you left in PR description: could you please add them as .xml performance tests in tests/performance folder? Especially the ones benchmarking ColumnVector. As far as I can tell, we have no existing test that isolates this path. It'd be great to include multiple element widths (not only 4 bytes). This PR doesn't target them all, but it would give us broader coverage for future work
| /// We see no benefit from using AVX512BW or AVX512F (over AVX2), so we only declare SSE and AVX2 | ||
| if (isArchSupported(TargetArch::x86_64_v3)) | ||
| return findExtremeImpl_x86_64_v3<T, ComparatorClass, add_all_elements, add_if_cond_zero>(ptr, condition_map, start, end); | ||
| #elif USE_ARM_MULTITARGET_CODE |
| using ArrayA = typename ColVecA::Container; | ||
| using ArrayC = typename ColVecC::Container; | ||
|
|
||
| MULTITARGET_FUNCTION_X86_V4_V3( |
bd2e757 to
cdb82ba
Compare
Added the queries in
We cannot use |
|
Hi @rienath, just following up, could you please take another look when you get a chance? |
rienath
left a comment
There was a problem hiding this comment.
A few more comments. Could you also please merge the master? It'd be also great if you gave me rights to commit to this branch, but it's ok if you don't. When CI is red because of some other problems, I'd wait for the fix and merge the master without pinging you. Thanks!
…hs for ColumnVector filtering, unary arithmetic, and findExtreme
cdb82ba to
4e71de5
Compare
| { | ||
| svbool_t filt_mask = svcmpne(FILT_LOAD_PRED, | ||
| svld1ub_u32(FILT_LOAD_PRED, reinterpret_cast<const uint8_t *>(filt_pos + i)), 0); | ||
| svuint32_t vec = svld1(ALL_TRUE, reinterpret_cast<const uint32_t *>(data_pos + i)); |
There was a problem hiding this comment.
ColumnVector<T>::filter now routes every sizeof(T) == 4 column through this SVE path, including Float32 and IPv4 from the new performance test, but the compact loop accesses the column storage through uint32_t *. That is not type-compatible for Float32 or the IPv4 strong typedef, so optimized builds can treat this as a strict-aliasing violation and miscompile the filter result.
Please keep the SVE load/store type-compatible, for example by selecting svfloat32_t / svint32_t / svuint32_t with if constexpr and handling strong typedefs through their actual underlying storage, or by restricting this fast path to the 4-byte types that can be legally accessed this way.
There was a problem hiding this comment.
SVE load/store and svcompact just perform data movement. No arithmetic operations are being performed. Still, if this causes miscompilation, we can use if constexpr, but this will tie the implementation to specific data types.
@rienath Apologies for the delayed rebase. Due to a recent commit, there were many changes to the AVX infrastructure, causing many merge conflicts, especially due to the renaming of USE_MULTITARGET_CODE to USE_X86_MULTITARGET_CODE. Can we decouple the ColumnVector filter portion from the rest of the PR (i.e., SVE infrastructure, optimized paths for unary arithmetic, findExtreme, etc.)? They already have proven benefit from the perf scripts, and this will make the PR more manageable.
There was a problem hiding this comment.
@chiranmoyf yes, go for it. Would it be possible to leave at least one path s.t. we can verify that it indeed works after the changes?
LLVM Coverage ReportChanged lines: Changed C/C++ lines covered by tests: 151/168 (89.88%) | Lost baseline coverage (was covered on master, now uncovered in this PR): 10 line(s) · Uncovered code |



Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Add ARM SVE detection and SVE dispatch infrastructure on AArch64.
Rename
USE_MULTITARGET_CODEtoUSE_X86_MULTITARGET_CODEand introduceUSE_ARM_MULTITARGET_CODEfor AArch64.Add
MULTITARGET_FUNCTION_ARM_SVEand extendMULTITARGET_FUNCTION_X86_V4_V3toMULTITARGET_FUNCTION_X86_V4_V3_ARM_SVE, andMULTITARGET_FUNCTION_X86_V4toMULTITARGET_FUNCTION_X86_V4_ARM_SVE.Add dispatchers for unary arithmetic and findExtreme functions. Performance improvements for several example functions on m7g.8xlarge - pastila.
Optimize ColumnVector filter operation using
svcompact.svcompactonly supports 4/8-byte datatypes. Testing shows performance improvement for 4-byte datatypes such asUInt32,Float32, andIPv4. Performance improvements on m7g.8xlarge - pastila.