Refactor cpuid by AntoinePrv · Pull Request #1251 · xtensor-stack/xsimd

AntoinePrv · 2026-01-30T11:31:35Z

This is a no-addition, non-breaking refactor of existing CPU id features as first class citizen as part of #1245.

Two individual and simple classes parsing for XCR0 and CPUID
The classes/header is safe on all platform, avoiding
supported_arch keeps the same structure and merges use of both class at the moment but both class could be combined a user-friendly x86_cpu_features.

serge-sans-paille

Some early review, a few open questions but nothing looks bad here. Way to go!

serge-sans-paille · 2026-01-30T16:20:36Z

include/xsimd/xsimd_cpu_features_x86.hpp

+    {
+        inline void get_cpuid(int reg[4], int level, int count = 0) noexcept;
+
+        inline std::uint32_t get_xcr0_low() noexcept;


it would be good to somehow ensure that this type is the same as ref_t

And this could be a private static method for better encapsulation right?

include/xsimd/xsimd_cpu_features_x86.hpp

include/xsimd/utils/bits.hpp

serge-sans-paille · 2026-01-30T16:25:27Z

include/xsimd/xsimd_cpu_features_x86.hpp

+        constexpr bool fma4() const noexcept
+        {
+            return utils::bit_is_set<16>(m_regs.reg8[2]);
+        }


Open question: should we have a macro that makes the generation of those field cleaner to the eye?

Either way. I am personally not big on macros. I find it easier read this way (could also be made to fit on one line) and find&replace is quite enough a change is required.

serge-sans-paille · 2026-01-30T16:27:14Z

include/xsimd/xsimd_cpu_features_x86.hpp

+
+    namespace detail
+    {
+        inline void get_cpuid(int reg[4], int level, int count) noexcept


Same here: could be private for better encapsulation.

On the contrary, I was wondering whether to make it part of public API.
It's a well defined function, unlikely to change, and that could be useful for users to get features we do not expose (not sure we'll go to cover 100% of cpuid).

serge-sans-paille · 2026-01-30T16:27:40Z

include/xsimd/types/xsimd_all_registers.hpp

 * The full license is in the file LICENSE, distributed with this software. *
 ****************************************************************************/

+#include "../config/xsimd_inline.hpp"


why do you need this?

It for header including what they use (otherwise I get nasty errors in my editor).
But this one did not belong here but in xsimd_register.hpp where XSIMD_INLINE is used.

AntoinePrv

Comments on change may make relative to the previous implementation

AntoinePrv · 2026-02-02T10:53:19Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+#elif defined(__INTEL_COMPILER)
+            __cpuid(reg.data(), level);


Should we change to use inline ASM for intel compiler? Missing the count option here.

I assumle so, feel free to give it a try!

AntoinePrv · 2026-02-02T10:54:31Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+#elif defined(_MSC_VER) && _MSC_VER >= 1400
+            return static_cast<xcr0_reg_t>(_xgetbv(0));
+
+#elif defined(__GNUC__)


What about __clang__ and __INTEL_COMPILER? Should we reproduce the get_cpuid pattern?

Yes, I think so. Also, IIRC, __clang__ comes with __GNUC__ defined too, and Intel compiler defines __GNUC__ or _MSC_VER depending on the platform. So we may simplify this logic (but first we need to verify that my asumption is right).

It's true that clang defines __GNUC__. And it happens to be true for icx too, see https://godbolt.org/z/56j57vhnT

AntoinePrv · 2026-02-03T09:07:42Z

@serge-sans-paille what do you think of this?

I wanted to add an x86_cpu_features that mixed xcr0, cpuid, as well as future opinionated features (e.g. override avx2 detection from cpuid if the specific implementation is known not to be performant).
However today that felt very redundant, perhaps in the future if we simplify the logic of supported_arch.

include/xsimd/xsimd_cpu_features_x86.hpp

include/xsimd/config/xsimd_cpu_features_x86.hpp

JohanMabille · 2026-02-19T14:28:33Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+#elif defined(_MSC_VER) && _MSC_VER >= 1400
+            return static_cast<xcr0_reg_t>(_xgetbv(0));
+
+#elif defined(__GNUC__)


Yes, I think so. Also, IIRC, __clang__ comes with __GNUC__ defined too, and Intel compiler defines __GNUC__ or _MSC_VER depending on the platform. So we may simplify this logic (but first we need to verify that my asumption is right).

serge-sans-paille · 2026-02-20T21:49:53Z

@AntoinePrv please ping me when you need a review!

AntoinePrv · 2026-02-23T08:26:46Z

@serge-sans-paille this is ready. This is intended to make a clean abstraction for CPUID.
In follow-up PRs, I will:

Add some sort of similar abstraction for arm64
Propose a generic user-facing interface.

include/xsimd/config/xsimd_cpu_features_x86.hpp

serge-sans-paille · 2026-02-23T11:54:41Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+            regs.reg1 = detail::get_cpuid(0x1);
+            regs.reg7 = detail::get_cpuid(0x7);
+            regs.reg7a = detail::get_cpuid(0x7, 0x1);
+            regs.reg8 = detail::get_cpuid(0x80000001);


Open question: could we avoid some get_cpuid call in some situation? For instance reg8 is only used for fma4, and reg7 for avx2 or later, which mean we could skip filling reg7 if we don't have avx, and fma4 if have fma3.

Let's postpone this as a further optimization then?

serge-sans-paille · 2026-02-23T11:55:35Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+#elif defined(__INTEL_COMPILER)
+            __cpuid(reg.data(), level);


I assumle so, feel free to give it a try!

include/xsimd/config/xsimd_cpu_features_x86.hpp

serge-sans-paille · 2026-02-23T12:00:54Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+#elif defined(_MSC_VER) && _MSC_VER >= 1400
+            return static_cast<xcr0_reg_t>(_xgetbv(0));
+
+#elif defined(__GNUC__)


It's true that clang defines __GNUC__. And it happens to be true for icx too, see https://godbolt.org/z/56j57vhnT

include/xsimd/config/xsimd_cpuid.hpp

include/xsimd/utils/bits.hpp

AntoinePrv · 2026-02-25T08:59:42Z

@serge-sans-paille in 1/2 day I can push another commit (easily revertable) with things I've been trying lately.
Basically the idea is to wrap individual register with strongly typed bitset exposed by an enum (essentially what is done for xcr0).

serge-sans-paille · 2026-02-25T09:01:10Z

ok, ping me when you need an extra pair of eyes.

AntoinePrv · 2026-02-25T15:10:22Z

@serge-sans-paille with this last commit we have

uint_bitset is a generic type that wrap any integer + enum into a strongly typed and descriptive bit set
It's used for all reading all registers
Raw classes such as x86_xcr0 or x86_cpuid_leaf1 can be used as to read and parse registers with strongly typed enums, no more, no less.
x86_cpu_features is an advanced class that combine CPUID results with XCR0 permissions. It is also lazy, reading CPUID registers as needed, including short circuiting if a permission would return false anyways. We can also use the class in the future to override if certain platforms are known to give inaccurate replies.

It's more LOC (though there is more documentation now, and many empty classes / brace lines), but it's also more declarative from now on. We just need to add more members to the enums to read other things.
x86_cpu_features on the contrary feels a bit repetitive, though I am not sure if there is a way to intelligently match permissions and cpu features without more boilerplate.

If you like the design I'd be happy to add tests for all classes with know implications (e.g. sse2 is always true on x86_64, avx2 implies avx and sse4.2...).

serge-sans-paille · 2026-02-26T07:05:09Z

include/xsimd/config/xsimd_cpuid.hpp

+                ssse3 = x86_cpu.ssse3();
+                sse4_1 = x86_cpu.sse4_1();
+                sse4_2 = x86_cpu.sse4_2();
+                fma3_sse42 = x86_cpu.fma3();


do you think you could have supported_arch inherit from x86_cpu to avoid this sequence of assignment?

Absolutely, this piece of code was meant as temporary.
Though I planned to this this in follow-up PR, once this and arm64_cpu_features is done.

JohanMabille · 2026-02-26T10:46:14Z

include/xsimd/config/xsimd_cpu_features_x86.hpp

+                return x86_cpuid_regs(detail::x86_cpuid(leaf, subleaf));
+            }
+
+            constexpr x86_cpuid_regs() noexcept = default;


I'm still not convinced by the need for this default constructor.

IMHO types without a default constructor are a pain to work with.
This default constructor is well defined, it returns all zeros bitsets.
In fact we use it in this very file for the lazy reading in x86_cpu_features:

Create well-defined but empty x86_cpuid_regs when creating x86_cpu_features.

Replace them as with a "read" version as needed.

I think I understand you point of view, that is may be weird to have the default ctor for a type intended to read a register, that does not do that. Perhpas this is more of an aggregate parser...

JohanMabille · 2026-02-26T10:50:05Z

include/xsimd/utils/bits.hpp

+        {
+            constexpr I mask = make_bit_mask<I>(static_cast<I>(Bit));
+            return value | mask;
+        }


Why having these free functions instead of having their implementation in the uint_bitset class directly? Do you plan to reuse them elsewhere?

Good point, they came before uint_bitset, that is why they are here.
Either way. I could see constexpr bit manipulation utilities used in the rest of xsimd instead of magic numbers.

serge-sans-paille reviewed Jan 30, 2026

View reviewed changes

AntoinePrv force-pushed the cpuid branch from b62ca87 to a450fa7 Compare February 2, 2026 10:52

AntoinePrv commented Feb 2, 2026

View reviewed changes

AntoinePrv force-pushed the cpuid branch from a450fa7 to f2c5403 Compare February 2, 2026 14:49

AntoinePrv marked this pull request as draft February 2, 2026 17:18

AntoinePrv marked this pull request as ready for review February 4, 2026 10:13

AntoinePrv force-pushed the cpuid branch from 01ec79e to cf96d20 Compare February 18, 2026 16:05

JohanMabille reviewed Feb 19, 2026

View reviewed changes

AntoinePrv added 15 commits February 19, 2026 17:48

Refactor x86 CPU features

1482e8e

Remove unsafe memset

44ab310

Fix warning

3c0af6f

Fix inline

f4a8fae

Refactor bit utils

e27e3fe

Fix inline header in wrong location

a5b1732

Fix cpuid aliases

a5f9338

Add future TODO

d324351

Fix missing var

1691bad

Com[act lines

525e8f8

Add doc

a5cdb36

Shorter name

f629a99

Add default minimal factory for xcr0

db51ffe

Move cpu features to config

bde1481

Make register class implementation private

8083e0c

AntoinePrv force-pushed the cpuid branch from cf96d20 to 8083e0c Compare February 19, 2026 16:48

Document all xcr0 bits

363258b

AntoinePrv force-pushed the cpuid branch from de6053a to 363258b Compare February 19, 2026 17:15

serge-sans-paille reviewed Feb 23, 2026

View reviewed changes

AntoinePrv added 2 commits February 24, 2026 10:37

Improve x86 cpu feature code clarity

ad8556a

Refine documentation

152b694

AntoinePrv force-pushed the cpuid branch from acf30de to 152b694 Compare February 25, 2026 08:20

AntoinePrv added 2 commits February 25, 2026 10:18

Use uint32_t for all registers

90e2a37

Rename with x86 prefix

607dbe8

AntoinePrv force-pushed the cpuid branch 2 times, most recently from dd51e01 to d63a75f Compare February 25, 2026 14:49

Refactor with strong typed bitset

1d6c0bf

AntoinePrv force-pushed the cpuid branch from d63a75f to 1d6c0bf Compare February 25, 2026 14:57

serge-sans-paille reviewed Feb 26, 2026

View reviewed changes

JohanMabille reviewed Feb 26, 2026

View reviewed changes

Conversation

AntoinePrv commented Jan 30, 2026

Uh oh!

serge-sans-paille left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AntoinePrv Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AntoinePrv left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JohanMabille Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AntoinePrv commented Feb 3, 2026

Uh oh!

Uh oh!

Uh oh!

JohanMabille Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

serge-sans-paille commented Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AntoinePrv commented Feb 23, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AntoinePrv commented Feb 25, 2026

Uh oh!

serge-sans-paille commented Feb 25, 2026 via email

Uh oh!

AntoinePrv commented Feb 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AntoinePrv Jan 30, 2026 •

edited

Loading

JohanMabille Feb 19, 2026 •

edited

Loading

JohanMabille Feb 19, 2026 •

edited

Loading

serge-sans-paille commented Feb 20, 2026 •

edited

Loading