On 10/14/25 9:32 AM, Tomasz Kaminski wrote:
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";
Spelling here.
};
};
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
Uh-oh, I have been putting them at the end.
Should I make a patch to fix mine?
- 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
──────────────────────────────────────────────────────────────────────────
