On Tue, Oct 28, 2025 at 11:37 AM Matthias Kretz <[email protected]> wrote:
> Tomasz Kaminski [Tuesday, 28 October 2025, 10:51:23 CET]: > > > * include/bits/vec_ops.h: New file. > > > * include/bits/version.def: Add simd. > > > * include/bits/version.h: Regenerate. > > > * include/std/simd: New file. > > > > The declarations from simd needs to also be exported from std module, > > so libstdc++-v3/src/c++23/std.cc.in needs to be edited to support it. > > But I think we could do that as a separate commit. > > I think that was all you wrote in this mail, right? > > Can you either delete the rest of the quoted mail or somehow mark your > last > comment so that I know I can stop looking? > I will do that. > > RFC: > > I have started to copy my tests over into testsuite/26_numerics/simd. But > as > with std::experimental::simd, I don't know where to stop. A thorough test > needs > > template for (constexpr int n : _IotaArray<67>) // or more > (test<simd::vec<all_vectorizable_types, n>>()...); > > but that exceeds any reasonable resource usage by far. It compiles for > hours > if you have TBs of memory (I guess — I don't). > I would aim to test code paths once, and use 1, 2, many approach, I would test one enabled and disabled integer type, floating point type, some type that is not vectorizable. Then for elements, 1, default, too many. I would focus them more on checking that constraints are correct, and working as expected. I.e. that the constructor is explicit when it should be (is_convertible). So, I can quickly validate what was the intent of this constrains, and if my change broke them. > > And is there a way to specify tests need to run with -march=x86-64, > -march=x86-64-v2, -march=x86-64-v3, … ? I can select one per .cc file and > then > include the actual test, right? The proper way is to run with a > target_list > argument to runtest, but can that be part of the check target? > I would still assume that we should use target_list for testing on various marches, in the single test just to make sure that we do not run the test on targets that are not intended. You could put a recommended target list in the commit message for commit with tests. > > - Matthias > > -- > ────────────────────────────────────────────────────────────────────────── > Dr. Matthias Kretz https://mattkretz.github.io > GSI Helmholtz Center for Heavy Ion Research https://gsi.de > std::simd > ────────────────────────────────────────────────────────────────────────── >
