On Tue, Oct 14, 2025 at 3:18 PM Matthias Kretz <[email protected]> wrote:
> 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.
>
Yes, that makes sense. My comments are not complete, I just started to read
through
to get a general understanding of how these all fit together, and commented
on smaller
things.
>
> Wrt tests, can you point me to
> - in what directory they should go,
>
I will go for testsuite/26_numerics/simd or testuite/std/simd.
> - the naming convention to use,
>
A lot of them are just named 1.cc/2.cc, but I prefer a more descriptive
name.
I would go for having bitops.cc, load.cc, store.cc e.t.c.
If the test goes too big, maky have a subdirectory.
> - your recommendation of a test to learn/copy from.
>
I found libstdc++-v3/testsuite/23_containers/flat_map/1.cc to be very
useful when I was starting, Also testsuite/std/format directory.
>
> I think I still know how to disable the tests for pre-C++26 and non-x86.
>
// { dg-do compile { target x86_64-*-linux* } }
And combined with C++26.
>
> Oh, and I looked at bits/version.* and I'm not sure I got it yet. I would
> modify bits/version.def,
ftms = {
name = simd;
values = {
// TODO fix
no_stdname = yes;
v = 201902;
cxxmin = 26;
extra_cond = "__cpp_strucutred_bindings";
};
};
And regenerate versions
> 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.
Yes. std//format again is good example:
#include <bits/requires_hosted.h> // for std::string
#define __glibcxx_want_format
#define __glibcxx_want_format_ranges
#define __glibcxx_want_format_uchar
#include <bits/version.h>
#define __glibcxx_format
...
#endif
> That's it? Topological sort means simd simply
> goes at the end of the file for now?
>
version.def is done alphabetically
>
> - 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
> ──────────────────────────────────────────────────────────────────────────
>
