> From: Nathan Bossart <nathandbossart@gmail.com>
> Sent: Friday, March 29, 2024 9:17 AM
> To: Amonson, Paul D <paul.d.amonson@intel.com>
> On Fri, Mar 29, 2024 at 04:06:17PM +0000, Amonson, Paul D wrote:
>> Yeah, I understand that much, but I want to know how portable the
>> XGETBV instruction is. Unless I can assume that all x86_64 systems
>> and compilers support that instruction, we might need an additional
>> configure check and/or CPUID check. It looks like MSVC has had
>> support for the _xgetbv intrinsic for quite a while, but I'm still researching the other cases.
>
> I see google web references to the xgetbv instruction as far back as
> 2009 for Intel 64 bit HW and 2010 for AMD 64bit HW, maybe you could
> test for
> _xgetbv() MSVC built-in. How far back do you need to go?
> Hm. It seems unlikely that a compiler would understand AVX512 intrinsics and not XGETBV then. I guess the other
questionis whether CPUID indicating AVX512 is enabled implies the availability of XGETBV on the CPU.
> If that's not safe, we might need to add another CPUID test.
> It would probably be easy enough to add a couple of tests for this, but if we don't have reason to believe there's
anypractical case to do so, I don't know why we would. I'm curious what others think about this.
This seems unlikely. Machines supporting XGETBV would support AVX512 intrinsics. Xgetbv instruction seems to be part of
xsavefeature set as per intel developer manual [2]. XGETBV/XSAVE came first, and seems to be available in all x86
systemsavailable since 2011, since Intel SandyBridge architecture and AMD the Opteron Gen4 [0].
AVX512 first came into a product in 2016 [1]
[0]: https://kb.vmware.com/s/article/1005764
[1]: https://en.wikipedia.org/wiki/AVX-512
[2]: https://cdrdv2-public.intel.com/774475/252046-sdm-change-document.pdf
- Akash Shankaran