Hi, I think that should be possible. bit and math is trivial to exclude. simd_complex.h is trivial. The parts in simd_mask.h and simd_vec.h are slightly harder but likely not a big deal. I should be able to not remove too much — I can't guarantee that I remove everything that could be removed.
In any case, it's a challenge to continue implementation of [simd] (the missing sections and support for ARM and POWER) while implementing PR feedback. Making the PR smaller could make that easier or harder, I can't say. I'll push a new set of branches to my fork and will open a new PR. Unless you object, that PR will be a single commit of the reduced feature set. I'd also implement as much of your feedback as I can do quickly. After pushing the implementation I'll work on a small set of tests. Wrt tests, can you point me to - in what directory they should go, - the naming convention to use, - your recommendation of a test to learn/copy from. I think I still know how to disable the tests for pre-C++26 and non-x86. Oh, and I looked at bits/version.* and I'm not sure I got it yet. I would modify bits/version.def, include <bits/version.h> from std/simd (and not from any of the bits/simd_*.h files) and then make inclusion of bits/simd_*.h conditional on __glibcxx_simd. That's it? Topological sort means simd simply goes at the end of the file for now? - Matthias Tomasz Kaminski [Monday, 13 October 2025, 18:11:59 CEST]: > Hi, > > I have looked throu the patches, and my preference would be to split the > work on simd, > into the chunks that get reviewed and landated into the trunk branch. So > multiple patch series. > This will require some effort on your part into reshuffling the comments, > so I would like to hear > your opinion on that first. > > With the mdspan, we have worked by having an internal feature test macro > exposed with value > one (so no_stdname in version.def), until we have complete implementation. > > What i would suggest would be to have: > 1) simd::vec, simd::mask and basic math ops for integral/floating point > types, > a difference here from existing patches would be that we will not > include > parts related to complex (bit_mask handling, _M_complex functions from > basic_simd_vec) > 2) bit operations for simd > 3) math operations for simd > 4) simd from complex > > I have also realized that the patches do not include any test for simd, > this make is very hard > to review, as I do not have any example to check, work on. So having some > minimal test suite > in repo would be valuable from a review point. > > Again, this will make the submission less convenient on your end, so please > let me know if that > is workable. If not I will try to continue on the forge in the form we have > currently. > > On Fri, Oct 10, 2025 at 5:40 PM Matthias Kretz <[email protected]> wrote: > > Tomasz Kaminski [Friday, 10 October 2025, 17:18:15 CEST]: > > > No need to do it when the patch is available on forge. We can iterate > > > > there. > > > > Do you prefer if I add commits and rebase/squash/fixup only when we're > > done, > > or do you prefer if I force-push changes? > > > > Also, should I simply keeping the mailing lists up to date by writing a > > mail > > to this thread whenever the forge's PR needs re-review? > > > > -- > > ────────────────────────────────────────────────────────────────────────── > > > > Dr. Matthias Kretz https://mattkretz.github.io > > GSI Helmholtz Center for Heavy Ion Research https://gsi.de > > std::simd > > > > ────────────────────────────────────────────────────────────────────────── -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Center for Heavy Ion Research https://gsi.de std::simd ──────────────────────────────────────────────────────────────────────────
