[PATCH 00/11] C++26 [simd]

Tue Oct 14 13:43:57 GMT 2025

On 10/14/25 9:32 AM, Tomasz Kaminski wrote:
> On Tue, Oct 14, 2025 at 3:18 PM Matthias Kretz <m.kretz@gsi.de> 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 <m.kretz@gsi.de> 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
>> ──────────────────────────────────────────────────────────────────────────
>>
> 