A cross platform C99 library to get cpu features at runtime.

Overview

cpu_features Build Status Build status

A cross-platform C library to retrieve CPU features (such as available instructions) at runtime.

Table of Contents

Design Rationale

  • Simple to use. See the snippets below for examples.
  • Extensible. Easy to add missing features or architectures.
  • Compatible with old compilers and available on many architectures so it can be used widely. To ensure that cpu_features works on as many platforms as possible, we implemented it in a highly portable version of C: C99.
  • Sandbox-compatible. The library uses a variety of strategies to cope with sandboxed environments or when cpuid is unavailable. This is useful when running integration tests in hermetic environments.
  • Thread safe, no memory allocation, and raises no exceptions. cpu_features is suitable for implementing fundamental libc functions like malloc, memcpy, and memcmp.
  • Unit tested.

Code samples

Note: For C++ code, the library functions are defined in the CpuFeatures namespace.

Checking features at runtime

Here's a simple example that executes a codepath if the CPU supports both the AES and the SSE4.2 instruction sets:

#include "cpuinfo_x86.h"

// For C++, add `using namespace CpuFeatures;`
static const X86Features features = GetX86Info().features;

void Compute(void) {
  if (features.aes && features.sse4_2) {
    // Run optimized code.
  } else {
    // Run standard code.
  }
}

Caching for faster evaluation of complex checks

If you wish, you can read all the features at once into a global variable, and then query for the specific features you care about. Below, we store all the ARM features and then check whether AES and NEON are supported.

#include <stdbool.h>
#include "cpuinfo_arm.h"

// For C++, add `using namespace CpuFeatures;`
static const ArmFeatures features = GetArmInfo().features;
static const bool has_aes_and_neon = features.aes && features.neon;

// use has_aes_and_neon.

This is a good approach to take if you're checking for combinations of features when using a compiler that is slow to extract individual bits from bit-packed structures.

Checking compile time flags

The following code determines whether the compiler was told to use the AVX instruction set (e.g., g++ -mavx) and sets has_avx accordingly.

#include <stdbool.h>
#include "cpuinfo_x86.h"

// For C++, add `using namespace CpuFeatures;`
static const X86Features features = GetX86Info().features;
static const bool has_avx = CPU_FEATURES_COMPILED_X86_AVX || features.avx;

// use has_avx.

CPU_FEATURES_COMPILED_X86_AVX is set to 1 if the compiler was instructed to use AVX and 0 otherwise, combining compile time and runtime knowledge.

Rejecting poor hardware implementations based on microarchitecture

On x86, the first incarnation of a feature in a microarchitecture might not be the most efficient (e.g. AVX on Sandy Bridge). We provide a function to retrieve the underlying microarchitecture so you can decide whether to use it.

Below, has_fast_avx is set to 1 if the CPU supports the AVX instruction set—but only if it's not Sandy Bridge.

#include <stdbool.h>
#include "cpuinfo_x86.h"

// For C++, add `using namespace CpuFeatures;`
static const X86Info info = GetX86Info();
static const X86Microarchitecture uarch = GetX86Microarchitecture(&info);
static const bool has_fast_avx = info.features.avx && uarch != INTEL_SNB;

// use has_fast_avx.

This feature is currently available only for x86 microarchitectures.

Running sample code

Building cpu_features (check quickstart below) brings a small executable to test the library.

 % ./build/list_cpu_features
arch            : x86
brand           :        Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz
family          :   6 (0x06)
model           :  45 (0x2D)
stepping        :   7 (0x07)
uarch           : INTEL_SNB
flags           : aes,avx,cx16,smx,sse4_1,sse4_2,ssse3
% ./build/list_cpu_features --json
{"arch":"x86","brand":"       Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz","family":6,"model":45,"stepping":7,"uarch":"INTEL_SNB","flags":["aes","avx","cx16","smx","sse4_1","sse4_2","ssse3"]}

What's supported

x86³ ARM AArch64 MIPS⁴ POWER
Android yes² yes¹ yes¹ yes¹ N/A
iOS N/A not yet not yet N/A N/A
Linux yes² yes¹ yes¹ yes¹ yes¹
MacOs yes² N/A not yet N/A no
Windows yes² not yet not yet N/A N/A
  1. Features revealed from Linux. We gather data from several sources depending on availability:
    • from glibc's getauxval
    • by parsing /proc/self/auxv
    • by parsing /proc/cpuinfo
  2. Features revealed from CPU. features are retrieved by using the cpuid instruction.
  3. Microarchitecture detection. On x86 some features are not always implemented efficiently in hardware (e.g. AVX on Sandybridge). Exposing the microarchitecture allows the client to reject particular microarchitectures.
  4. All flavors of Mips are supported, little and big endian as well as 32/64 bits.

Android NDK's drop in replacement

cpu_features is now officially supporting Android and offers a drop in replacement of for the NDK's cpu-features.h , see ndk_compat folder for details.

License

The cpu_features library is licensed under the terms of the Apache license. See LICENSE for more information.

Build with CMake

Please check the CMake build instructions.

Quickstart with Ninja

  • build list_cpu_features
    cmake -B/tmp/cpu_features -H. -GNinja -DCMAKE_BUILD_TYPE=Release
    ninja -C/tmp/cpu_features
    /tmp/cpu_features/list_cpu_features --json
  • run tests
    cmake -B/tmp/cpu_features -H. -GNinja -DBUILD_TESTING=ON
    ninja -C/tmp/cpu_features
    ninja -C/tmp/cpu_features test
Comments
  • ARM64 detection via asm

    ARM64 detection via asm

    Added an initial implementation, detecting ARM64 through assembly instructions, thereby getting rid of OS binding, which can be used, for example, to detect ARM on Windows.

    What do you think?

    opened by toor1245 19
  • Intel(R) Xeon(R) Platinum 8275CL detected as skylake

    Intel(R) Xeon(R) Platinum 8275CL detected as skylake

    On a AWS C5 machine:

    $ lscpu
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                8
    On-line CPU(s) list:   0-7
    Thread(s) per core:    2
    Core(s) per socket:    4
    Socket(s):             1
    NUMA node(s):          1
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 85
    Model name:            Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz
    Stepping:              7
    CPU MHz:               2999.998
    BogoMIPS:              5999.99
    Hypervisor vendor:     KVM
    Virtualization type:   full
    L1d cache:             32K
    L1i cache:             32K
    L2 cache:              1024K
    L3 cache:              36608K
    NUMA node0 CPU(s):     0-7
    Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 ida arat pku ospke
    

    but

    [[email protected]_perf bin]$ ./list_cpu_features 
    arch            : x86
    brand           : Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz
    family          :   6 (0x06)
    model           :  85 (0x55)
    stepping        :   7 (0x07)
    uarch           : INTEL_SKL
    flags           : aes,avx,avx2,avx512bw,avx512cd,avx512dq,avx512f,avx512vl,bmi1,bmi2,cx16,erms,f16c,fma3,movbe,popcnt,rdrnd,sse4_1,sse4_2,ssse3
    

    using commit 9613390. Trying with master ....

    bug 
    opened by WilliamTambellini 16
  • Explicitly namespace every extern identifier

    Explicitly namespace every extern identifier

    To avoid identifier collisions and fix https://github.com/google/cpu_features/issues/34, I moved every extern identifier into their own "namespace", by prefixing them with CpuFeatures_ (or CpuFeatures_ClassName_, for example for the StringView: CpuFeatures_StringView_).

    I'm aware this is a huge change, but it's, unfortunately, required since C has no explicit namespaces. The other option would be to migrate to C++ and use actual namespaces. I only did a search & replace for the identifiers, the change is likely to violate some 80 column limits and would need to be reformatted at some points.

    Tested and compiles on macOS.

    Edit: I also just realized I haven't updated the tests.

    opened by Leandros 16
  • add x86/avx512_fp16 detection

    add x86/avx512_fp16 detection

    For reference, on an alder-lake CPU with AVX512 (and therefore, AVX512_FP16 support) enabled:

    $ ./list_cpu_features
    arch            : x86
    brand           : 12th Gen Intel(R) Core(TM) i9-12900K
    family          :   6 (0x06)
    model           : 151 (0x97)
    stepping        :   2 (0x02)
    uarch           : INTEL_ADL
    flags           : adx,aes,avx,avx2,avx512_bf16,avx512_fp16,avx512_second_fma,avx512_vp2intersect,avx512bitalg,avx512bw,avx512cd,avx512dq,avx512f,avx512ifma,avx512vbmi,avx512vbmi2,avx512vl,avx512vnni,avx512vpopcntdq,avx_vnni,bmi1,bmi2,clflushopt,clfsh,clwb,cx16,cx8,erms,f16c,fma3,fpu,lzcnt,mmx,movbe,pclmulqdq,popcnt,rdrnd,rdseed,sha,smx,ss,sse,sse2,sse3,sse4_1,sse4_2,ssse3,tsc,vaes,vpclmulqdq
    cache_info      : {"level":1,"cache_type":"data","cache_size":49152,"ways":12,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":1,"cache_type":"instruction","cache_size":32768,"ways":8,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":2,"cache_type":"unified","cache_size":1310720,"ways":10,"line_size":64,"tlb_entries":2048,"partitioning":1},{"level":3,"cache_type":"unified","cache_size":31457280,"ways":12,"line_size":64,"tlb_entries":40960,"partitioning":1}
    

    On a tiger-lake laptop, predating AVX512_FP16 support:

    $ arch            : x86
    brand           : 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    family          :   6 (0x06)
    model           : 140 (0x8C)
    stepping        :   1 (0x01)
    uarch           : INTEL_TGL
    flags           : adx,aes,avx,avx2,avx512_second_fma,avx512_vp2intersect,avx512bitalg,avx512bw,avx512cd,avx512dq,avx512f,avx512ifma,avx512vbmi,avx512vbmi2,avx512vl,avx512vnni,avx512vpopcntdq,bmi1,bmi2,clflushopt,clfsh,clwb,cx16,cx8,erms,f16c,fma3,fpu,lzcnt,mmx,movbe,pclmulqdq,popcnt,rdrnd,rdseed,sha,ss,sse,sse2,sse3,sse4_1,sse4_2,ssse3,tsc,vaes,vpclmulqdq
    cache_info      : {"level":1,"cache_type":"data","cache_size":49152,"ways":12,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":1,"cache_type":"instruction","cache_size":32768,"ways":8,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":2,"cache_type":"unified","cache_size":1310720,"ways":20,"line_size":64,"tlb_entries":1024,"partitioning":1},{"level":3,"cache_type":"unified","cache_size":12582912,"ways":12,"line_size":64,"tlb_entries":16384,"partitioning":1}
    
    opened by damageboy 14
  • this is not c89

    this is not c89

    You've got a build system that depends on c++, // comments in your code, and you use the inline keyword in string_view.h, leaving aside the stdint.h includes and uintxx_t types scattered everywhere.

    Attempting to compile this even once with -std=c89 would have revealed these problems. I recommend you put, at least, set(CMAKE_C_FLAGS "-std=c89 ${CMAKE_C_FLAGS}") in your CMakeLists.txt file.

    bug 
    opened by khm 12
  • Detect AVX512 on Darwin use GetDarwinSysCtlByName(

    Detect AVX512 on Darwin use GetDarwinSysCtlByName("hw.optional.avx512f")

    Detect AVX512 on Darwin use GetDarwinSysCtlByName("hw.optional.avx512f")

    On the below CPU, darwin support AVX512 with on-demand.

    • https://github.com/apple/darwin-xnu/blob/xnu-7195.81.3/osfmk/i386/fpu.c#L173-L199
    arch            : x86
    brand           : Intel(R) Xeon(R) W-2150B CPU @ 3.00GHz
    family          :   6 (0x06)
    model           :  85 (0x55)
    stepping        :   4 (0x04)
    uarch           : INTEL_SKL
    .
    .
    

    sysctl result is here:

    $ sysctl hw.optional | grep avx512
    hw.optional.avx512bw: 1
    hw.optional.avx512cd: 1
    hw.optional.avx512dq: 1
    hw.optional.avx512f: 1
    hw.optional.avx512ifma: 0
    hw.optional.avx512vbmi: 0
    hw.optional.avx512vl: 1
    

    So, detect os_support.have_avx512 to use GetDarwinSysCtlByName("hw.optional.avx512f");, support Intel(R) Xeon AVX512 on Darwin OS.


    after patched result on the same CPU:

    arch            : x86
    brand           : Intel(R) Xeon(R) W-2150B CPU @ 3.00GHz
    family          :   6 (0x06)
    model           :  85 (0x55)
    stepping        :   4 (0x04)
    uarch           : INTEL_SKL
    flags           : aes,avx,avx2,avx512_second_fma,avx512bw,avx512cd,avx512dq,avx512f,avx512vl,bmi1,bmi2,clflushopt,clfsh,clwb,cx16,cx8,dca,erms,f16c,fma3,fpu,hle,mmx,movbe,pclmulqdq,popcnt,rdrnd,rdseed,rtm,smx,ss,sse,sse2,sse3,sse4_1,sse4_2,ssse3,tsc
    cache_info      : {"level":1,"cache_type":"data","cache_size":32768,"ways":8,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":1,"cache_type":"instruction","cache_size":32768,"ways":8,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":2,"cache_type":"unified","cache_size":1048576,"ways":16,"line_size":64,"tlb_entries":1024,"partitioning":1},{"level":3,"cache_type":"unified","cache_size":14417920,"ways":11,"line_size":64,"tlb_entries":20480,"partitioning":1}
    
    enhancement 
    opened by zchee 11
  • Adding support for Apple M1 AArch64 Architecture Processor.

    Adding support for Apple M1 AArch64 Architecture Processor.

    This is the initial attempt at adding support for the new Apple Silicon M1 cpu to cpu_features. Based on my own laptop I tried to make my best guess for how the ARM features map from the sysctl optional values to the AArch64Features.

    hw.optional.floatingpoint: 1
    hw.optional.watchpoint: 4
    hw.optional.breakpoint: 6
    hw.optional.neon: 1
    hw.optional.neon_hpfp: 1
    hw.optional.neon_fp16: 1
    hw.optional.armv8_1_atomics: 1
    hw.optional.armv8_crc32: 1
    hw.optional.armv8_2_fhm: 1
    hw.optional.armv8_2_sha512: 1
    hw.optional.armv8_2_sha3: 1
    hw.optional.amx_version: 2
    hw.optional.ucnormal_mem: 1
    hw.optional.arm64: 1
    

    I also tried to map between the variant, revision, part and implementor based on the following sysctl values. I'm not sure if I got them correct, but it is a good first stab at it.

    hw.cputype: 16777228
    hw.cpusubtype: 2
    hw.cpu64bit_capable: 1
    hw.cpufamily: 458787763
    hw.cpusubfamily: 2
    

    The output I get is:

    ./list_cpu_features
    arch            : aarch64
    implementer     : 16777228 (0x100000C)
    variant         :   2 (0x02)
    part            : 458787763 (0x1B588BB3)
    revision        :   2 (0x02)
    flags           : asimdfhm,atomics,crc32,fp,fphp,sha3,sha512
    

    This pull request is an effort to address: https://github.com/google/cpu_features/issues/121 https://github.com/gnuradio/volk/issues/428

    enhancement cmake Apple M1 
    opened by sbehnke 10
  • Building fails on Raspberry Pi OS when run with 64bit kernel since cpu_features mistakes the kernel's arch for userspace's

    Building fails on Raspberry Pi OS when run with 64bit kernel since cpu_features mistakes the kernel's arch for userspace's

    [email protected]:~/src/volk/cpu_features/build$ cmake ..
    -- The C compiler identification is GNU 8.3.0
    -- Check for working C compiler: /usr/bin/cc
    -- Check for working C compiler: /usr/bin/cc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Looking for dlfcn.h
    -- Looking for dlfcn.h - found
    -- Looking for getauxval
    -- Looking for getauxval - found
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/xxx/src/volk/cpu_features/build
    [email protected]:~/src/volk/cpu_features/build$ make
    Scanning dependencies of target utils
    [ 12%] Building C object CMakeFiles/utils.dir/src/filesystem.c.o
    [ 25%] Building C object CMakeFiles/utils.dir/src/stack_line_reader.c.o
    [ 37%] Building C object CMakeFiles/utils.dir/src/string_view.c.o
    [ 37%] Built target utils
    Scanning dependencies of target unix_based_hardware_detection
    [ 50%] Building C object CMakeFiles/unix_based_hardware_detection.dir/src/hwcaps.c.o
    [ 50%] Built target unix_based_hardware_detection
    Scanning dependencies of target cpu_features
    [ 62%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_aarch64.c.o
    In file included from /home/xxx/src/volk/cpu_features/src/cpuinfo_aarch64.c:15:
    /home/xxx/src/volk/cpu_features/include/cpuinfo_aarch64.h:153:2: error: #error "Including cpuinfo_aarch64.h from a non-aarch64 target."
     #error "Including cpuinfo_aarch64.h from a non-aarch64 target."
      ^~~~~
    make[2]: *** [CMakeFiles/cpu_features.dir/build.make:63: CMakeFiles/cpu_features.dir/src/cpuinfo_aarch64.c.o] Error 1
    make[1]: *** [CMakeFiles/Makefile2:111: CMakeFiles/cpu_features.dir/all] Error 2
    make: *** [Makefile:130: all] Error 2
    [email protected]:~/src/volk/cpu_features/build$ uname -a
    Linux pi4 5.4.72-v8+ #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020 aarch64 GNU/Linux
    [email protected]@pi4:~/src/volk/cpu_features/build$ file /bin/ls
    /bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=67a394390830ea3ab4e83b5811c66fea9784ee69, stripped
    

    So this is 64bit arm architecture with a 32bit userland. Default GCC target is correctly 32bit, since __aarch64__ doesn't seem to be defined.

    (again a problem that probably would have been avoided if people would just stop using cmake and use something working like autotools)

    cmake 
    opened by ThomasHabets 10
  • Unable to build this on macOS

    Unable to build this on macOS

    @gchatelet , I ran into an error while running this command on the macOS system

    
    Abhinavs-MacBook-Pro:cpu_features eklavya$ cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -H. -Bcmake_build
    -- The C compiler identification is AppleClang 9.1.0.9020039
    -- The CXX compiler identification is AppleClang 9.1.0.9020039
    -- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc
    -- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++
    -- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/eklavya/projects/code/c-shared-lab/cpu_features/cmake_build
    
    
    Abhinavs-MacBook-Pro:cpu_features eklavya$ cd cmake_build/
    
    
    Abhinavs-MacBook-Pro:cmake_build eklavya$ make 
    Scanning dependencies of target cpu_features
    [  6%] Building C object CMakeFiles/cpu_features.dir/src/linux_features_aggregator.c.o
    [ 13%] Building C object CMakeFiles/cpu_features.dir/src/cpuid_x86_clang_gcc.c.o
    [ 20%] Building C object CMakeFiles/cpu_features.dir/src/cpuid_x86_msvc.c.o
    [ 26%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_aarch64.c.o
    [ 33%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_arm.c.o
    [ 40%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_mips.c.o
    [ 46%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_ppc.c.o
    [ 53%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_x86.c.o
    [ 60%] Building C object CMakeFiles/cpu_features.dir/src/filesystem.c.o
    [ 66%] Building C object CMakeFiles/cpu_features.dir/src/hwcaps.c.o
    [ 73%] Building C object CMakeFiles/cpu_features.dir/src/stack_line_reader.c.o
    [ 80%] Building C object CMakeFiles/cpu_features.dir/src/string_view.c.o
    [ 86%] Linking C shared library libcpu_features.dylib
    Undefined symbols for architecture x86_64:
      "_CpuFeatures_GetPlatformType", referenced from:
          _GetPPCPlatformStrings in cpuinfo_ppc.c.o
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[2]: *** [libcpu_features.dylib] Error 1
    make[1]: *** [CMakeFiles/cpu_features.dir/all] Error 2
    make: *** [all] Error 2
    
    opened by abhi18av 9
  • list_cpu_features.exe does not detect SSE42 on Xeon X5650 (Windows)

    list_cpu_features.exe does not detect SSE42 on Xeon X5650 (Windows)

    Here is the documentation of that specific CPU: https://ark.intel.com/content/www/us/en/ark/products/47922/intel-xeon-processor-x5650-12m-cache-2-66-ghz-6-40-gts-intel-qpi.html

    Here is the output of list_cpu_features.exe:

    arch            : x86
    brand           : Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz
    family          :   6 (0x06)
    model           :  44 (0x2C)
    stepping        :   2 (0x02)
    uarch           : INTEL_WSM
    flags           : aes,clfsh,cx16,cx8,dca,fpu,mmx,pclmulqdq,popcnt,smx,ss,sse,sse2,sse3,tsc
    cache_info      : {"level":1,"cache_type":"data","cache_size":32768,"ways":8,"line_size":64,"tlb_entries":64,"partitioning":1},{"level":1,"cache_type":"instruction","cache_size":32768,"ways":4,"line_size":64,"tlb_entries":128,"partitioning":1},{"level":2,"cache_type":"unified","cache_size":262144,"ways":8,"line_size":64,"tlb_entries":512,"partitioning":1},{"level":3,"cache_type":"unified","cache_size":12582912,"ways":16,"line_size":64,"tlb_entries":12288,"partitioning":1}
    

    If booted into Linux, sse4_2 is found. Partial output from cat /proc/cpuinfo:

    processor       : 23
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 44
    model name      : Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz
    stepping        : 2
    microcode       : 0x1f
    cpu MHz         : 2925.936
    cache size      : 12288 KB
    physical id     : 0
    siblings        : 12
    core id         : 10
    cpu cores       : 6
    apicid          : 21
    initial apicid  : 21
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 11
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm ida arat flush_l1d
    bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
    bogomips        : 5319.94
    clflush size    : 64
    cache_alignment : 64
    address sizes   : 40 bits physical, 48 bits virtual
    power management:
    ...
    
    bug 
    opened by RainbowMiner 8
  • Fix a getauxval comment and expand the Krait idiv workaround

    Fix a getauxval comment and expand the Krait idiv workaround

    The next NDK (r24) raises the minimum supported Android API from 16 to 19. That's new enough that all supported targets with NDK r24 have the getauxval function. i.e. Maybe google/cpu_features can drop support for dlopen/dlsym of getauxval at some point.

    I noticed the lack of idiv support on my 2013 Nexus 7 device, because I used that device to run the NDK's tests. One of the tests verifies that the idiv support reported by the NDK cpu-features library matches what the device actually supports. Both the NDK's cpu-features and this cpu_features library only recognize the 0x510006f2 and 0x510006f3 CPU IDs for this workaround.

    See https://github.com/android/ndk/issues/1605.

    enhancement 
    opened by rprichard 7
  • Add RISC-V CI support

    Add RISC-V CI support

    This follow(Fix) or precede(TDD):

    • #272

    This PR add:

    • CI: Add riscv support
      • [x] Add bootlin toolchain in scripts/run_integration.sh
      • [x] Add riscv support in cmake/ci/Makefile
      • [x] Add riskv_linux_cmake.yml workflows
      • [x] Add RISCV to badge script (todo(gchatelet): rerun it to regenerate README.md)
    • Fixup: variable fixup in expand_bootlin (ed s/POWER_/TOOLCHAIN_/)

    note: I've sorted arch badges alphabetically...

    opened by Mizux 2
  • Add vcpkg installation instructions

    Add vcpkg installation instructions

    cpu_features available as a port in vcpkg, a C++ library manager that simplifies installation for cpu_features and other project dependencies. Documenting the install process here will help users get started by providing a single set of commands to build cpu_features, ready to be included in their projects.

    We also test whether our library ports build in various configurations (dynamic, static) on various platforms (OSX, Linux, Windows: x86, x64) to keep a wide coverage for users.

    I'm a maintainer for vcpkg, and here is what the port script looks like. We try to keep the library maintained as close as possible to the original library.

    opened by Adela0814 1
  • Add RISC-V support

    Add RISC-V support

    I added RISC-V architecture support on linux by parsing /proc/cpuinfo. It has been tested using QEMU emulator. I have done the following points:

    • features detection (i kept it as a single letter, is it fine or do i have to replace it with its description?)
    • microarchitecture detection (i'm not sure if it's correct, so check it carefully)
    • vendor detection Tests have been added as well
    opened by DaniAffCH 6
  • Move common logic of AArch64

    Move common logic of AArch64

    To implement support aarch64 for Windows, macOS and FreeBSD I moved common logic to src/impl_aarch64__base_implementation.inl which is consistency to x86 base impl

    Apple M1 
    opened by toor1245 0
  • Safety guarantees regarding code motion?

    Safety guarantees regarding code motion?

    Hi team,

    I'm working with the rust-lang team on a concern that would overlap with cpu_features, and am specifically here because this project has been around for a long time, is well regarded, and looks to be very mature and well-designed!

    My question is fairly simple - have you run into any issues due to a combination of inlined functions and code motion? Are there any steps the project itself takes or any guarantees that make you feel sufficiently confident that compiler optimizations can't cause instructions to be reordered out of the confines of the protective if statement?

    For example, if you had the following contrived code sample:

    #include "cpuinfo_x86.h"
    
    static const X86Features features = GetX86Info().features;
    
    void Compute(int m, int n) {
      int x, y;
      if (features.bmi2) {
        x = _bzhi_u32(m, n);
        y = x + 1;
      } else {
        y = m + n;
      }
    
      printf("%d\n", y);
    }
    

    Is there anything to prevent a (smart but not too smart) optimizing compiler from noticing that 1) _bzhi_u32() is a known, inlinable function with zero observable side effects, 2) x may be calculated without affecting the else branch, 3) features.bmi2 is always tested and changing the code to

    void Compute(int m, int n) {
      ...
      bzhi x, m, n;
      incr x;
      add y, m, n;
      test features.bmi2;
      cmov y, x;
      ...
    }
    

    (or just keeping the jmp but calculating bzhi beforehand)

    The project README doesn't mention that the burden is on a developer to make sure any code using the detected features in the if (features.foo) { ... } branch cannot be inlined to protect against code motion, so I'm wondering if there are any sections of the C or C++ specification or the GCC/LLVM internal APIs that document, e.g., code motion cannot happen across a non-inlined condition or anything else that would prevent a (compliant) compiler from generating code that possibly uses an unsupported instruction.

    opened by mqudsi 3
Releases(v0.7.0)
  • v0.7.0(Mar 8, 2022)

    API Change

    • [API Change] [x86] Embed brand_string and mark FillX86BrandString as deprecated #214
    • [API Change] New code layout - breaking change in cpu_features_macros.h #194

    New features / Enhancements

    • [enhancement][**cmake**] Use of CMAKE_POSITION_INDEPENDENT_CODE instead of BUILD_PIC #188
    • [enhancement] Add support for ZHAOXIN CPU #218
    • [enhancement] Fix a getauxval comment and expand the Krait idiv workaround #206
    • [enhancement] Update AArch64 features to Linux 5.10 #149
    • [enhancement] Detect Zen 3 (K19) cpus #152
    • [enhancement] Detect AVX512 on Darwin use GetDarwinSysCtlByName("hw.optional.avx512f") #153
    • [enhancement] Detect Intel's Multi-Precision Add-Carry Instruction Extensions #157
    • [enhancement] CPU features for AMD #165
    • [enhancement] Update uarch detection for Intel processors #184
    • [enhancement] Add cache info for new AMD CPUs (0x8000001D) #171
    • [enhancement] [NFC] Add bazel support to cpu_features #222
    • [enhancement] Add support for FreeBSD on x86 #163
    • [enhancement][**cmake**] cmake: use CTest default #170

    Bug Fixes

    • [bug] Fix list_cpu_features.exe does not detect SSE42 on Xeon X5650 (Windows) #220
    • [bug] replace sse3 detection with pni when reading /proc/cpuinfo #225
    • [bug][**cmake**] CMake: add BUNDLE DESTINATION to fix cross-build to iOS/watchOS/tvOS #177
    • [bug] Fix C++ namespace in README #156
    • [bug] Avoid leaking internal headers for ppc #164
    • [bug] github/workflows: fix install clang-format to use clang-extra-tools pkg #155
    • [bug] Fix include paths in BUILD #226
    • [bug] Fix arm64 detection precedence in CMakeLists.txt #209
    • [bug] cmake: Fix test enabling for ndk_compat #195
    • [bug] Fixes #185 #187
    • [bug] Fixes wrong cache detection of old processors #183
    • [bug] Fix windows amd64 ci #223
    • [bug][**cmake**] Fix: CMake googletest-download failed #202
    • [bug] Fix #140 Atom processor detected as X86_UNKNOWN #160

    Misc

    • [cleanup] fix: Return default value from ‘GetCacheTypeString’ #162
    • [cleanup] [NFC][x86] Read all cpuid leaves at once #213
    • [cleanup] Update README.md #193
    • [cleanup] ci: Migrate FreeBSD to macos-10.15 virtual env #191
    • [cleanup] Set CTest output on failure #189
    • [cleanup] [NFC] Change implementation of FillX86BrandString #181
    • [cleanup] Showcase community bindings #180
    • [cleanup] [NFC] refactor the code so it's easier to understand the execution flow #161
    • [cleanup] Rename 'master' branch into 'main' #219
    • [cleanup] Provides a release script #142
    • [cleanup] [NFC] Fix const cast #174
    • [cleanup] ci: Migrate to github actions #192
    • [cleanup] ci: Add docker containers to run toolchain jobs from various hosts #196
    • [cleanup] ci: Add GitHub workflows #166
    • [cleanup] ci: Add FreeBSD GitHub workflows #167
    • [cleanup] Update README.md (Fix #175) #176
    • [cleanup] Update gitignore #173
    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Oct 15, 2020)

  • v0.5.0(Sep 22, 2020)

    • [enhancement] Detect future Intel AVX/AMX features #128
    • [enhancement] Add support for Tiger Lake and Sapphire rapids Intel microarchitectures #127
    • [enhancement] Update features for AArch64 to Linux 5.8 #126
    • [enhancement] AVX-512 FMA count detection #120
    • [bug] CMake find_package() version mismatch #118
    • [enhancement] Add C++ namespace to docs #117
    • [bug] Fatal error: 'cpu-features.h' file not found #106
    • [bug] no member named 'vfpv' in 'ArmFeatures' when compiling ndk_compat for arm #96
    Source code(tar.gz)
    Source code(zip)
  • v0.4.1(Jul 16, 2019)

  • v0.4.0(Jul 11, 2019)

  • v0.3.0(Apr 30, 2019)

    • [bug] Link failure under centos 6 for the shared lib #65
    • [bug] Mips implementation is buggy #59
    • [enhancement] Add an easy way to migrate from the Android NDK #47
    • [bug] Unable to build this on ARMv7 server #46
    • [closed] Unable to build this on macOS #45
    • [closed] How to compile this as a shared library ? #44
    Source code(tar.gz)
    Source code(zip)
Owner
Google
Google ❤️ Open Source
Google
A cross-platform OpenXR capabilities explorer and runtime switcher with a CLI and GUI.

OpenXR Explorer OpenXR Explorer is a handy debug tool for OpenXR developers. It allows for easy switching between OpenXR runtimes, shows lists of the

Nick Klingensmith 150 Nov 24, 2022
A shebang-friendly script for "interpreting" single C99, C11, and C++ files, including rcfile support.

c99sh Basic Idea Control Files Shebang Tricks C++ C11 Credits Basic Idea A shebang-friendly script for "interpreting" single C99, C11, and C++ files,

Rhys Ulerich 101 Nov 12, 2022
A bullet-hell shooter game made in C99 for my college project.

Kosmos A bullet-hell shooter game made in C99 for my college project. Building Linux Install requied libraries Ubuntu sudo apt install libasound2-dev

Siddharth Roy 19 Nov 1, 2022
A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename.

whereami A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename. usag

Blackle Morisanchetto 3 Sep 24, 2022
GNU project's implementation of the standard C library(with Xuantie RISC-V CPU support).

GNU project's implementation of the standard C library(with Xuantie RISC-V CPU support).

T-Head Semiconductor Co., Ltd. 5 Mar 17, 2022
A cross-platform protocol library to communicate with iOS devices

libimobiledevice A library to communicate with services on iOS devices using native protocols. Features libimobiledevice is a cross-platform software

libimobiledevice 5.3k Nov 30, 2022
A Midnight Commander fork with scripting and other features.

⁝⁝⁝ ⋱הϵѻ⋱ Midnight Commander ⁝⁝⁝ Welcome to the ⋱Neo⋱-MC project! The goals of it are to: make the hidden gem – mcedit – shine and grow to be able to

null 136 Apr 23, 2021
Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux

Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux. Its main purpose is to help developers visualize the execution flow of a complex application.

Google 2.9k Nov 28, 2022
Simple yet fancy CPU architecture fetching tool

Simple yet fancy CPU architecture fetching tool

null 1.6k Nov 23, 2022
Hybrid Detect demonstrates CPU topology detection using multiple intrinsic and OS level APIs.

Hybrid Detect Hybrid Detect demonstrates CPU topology detection using multiple intrinsic and OS level APIs. First, we demonstrate usage of CPUID intri

null 34 Nov 12, 2022
Platform independent Near Field Communication (NFC) library

*- * Free/Libre Near Field Communication (NFC) library * * Libnfc historical contributors: * Copyright (C) 2009 Roel Verdult * Copyright (C) 2009

null 1.3k Nov 29, 2022
WAFer is a C language-based software platform for scalable server-side and networking applications. Think node.js for C programmers.

WAFer WAFer is a C language-based ultra-light scalable server-side web applications framework. Think node.js for C programmers. Because it's written i

Riolet Corporation 692 Nov 19, 2022
PRK is a keyboard firmware platform in PicoRuby

PRK is a keyboard firmware written and configured in PicoRuby which is an alternative mruby implementation targeting on one-chip microcontroller.

PicoRuby 380 Nov 22, 2022
Isocline is a pure C library that can be used as an alternative to the GNU readline library

Isocline: a portable readline alternative. Isocline is a pure C library that can be used as an alternative to the GNU readline library (latest release

Daan 135 Nov 25, 2022
Command-line arguments parsing library.

argparse argparse - A command line arguments parsing library in C (compatible with C++). Description This module is inspired by parse-options.c (git)

Yecheng Fu 527 Nov 27, 2022
Library that solves the exact cover problem using Dancing Links, also known as DLX.

The DLX Library The DLX library The DLX library solves instances of the exact cover problem, using Dancing Links (Knuth’s Algorithm X). Also included

Ben Lynn 43 Nov 7, 2022
Standards compliant, fast, secure markdown processing library in C

Hoedown Hoedown is a revived fork of Sundown, the Markdown parser based on the original code of the Upskirt library by Natacha Porté. Features Fully s

Hoedown 920 Nov 26, 2022
CommonMark parsing and rendering library and program in C

cmark cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. (For the JavaScript reference impl

CommonMark 1.4k Dec 1, 2022
A C library for parsing/normalizing street addresses around the world. Powered by statistical NLP and open geo data.

libpostal: international street address NLP libpostal is a C library for parsing/normalizing street addresses around the world using statistical NLP a

openvenues 3.6k Nov 23, 2022