Ответ 1
Как указано в комментариях, вы можете искать все файлы ELF вашей системы и разбирать их, чтобы проверить, используют ли они инструкции AVX-512:
$ objdump -d /lib64/ld-linux-x86-64.so.2 | grep %zmm0
14922: 62 f1 fd 48 7f 44 24 vmovdqa64 %zmm0,0xc0(%rsp)
14a2d: 62 f1 fd 48 6f 44 24 vmovdqa64 0xc0(%rsp),%zmm0
14c2c: 62 f1 fd 48 7f 81 50 vmovdqa64 %zmm0,0x50(%rcx)
14ca0: 62 f1 fd 48 6f 84 24 vmovdqa64 0x50(%rsp),%zmm0
(BTW, libc и ld.so включают инструкции AVX-512, они не те, что вы ищете?)
Однако вы можете найти двоичный файл, который вы даже не выполняете и не пропустите код, динамически несжатый и т.д.
Если у вас есть сомнения в процессе (так как perf отчета CORE_POWER.LVL*_TURBO_LICENSE событий), я предлагаю, чтобы создать основную свалку, если этот процесс и разобрать его (обратите внимание на первую строку позволяет также сбросить код):
$ echo 0xFF > /proc/<PID>/coredump_filter
$ gdb --pid=<PID>
[...]
(gdb) gcore
Saved corefile core.19602
(gdb) quit
Detaching from program: ..., process ...
$ objdump -d core.19602 | grep %zmm0
7f73db8187cb: 62 f1 7c 48 10 06 vmovups (%rsi),%zmm0
7f73db818802: 62 f1 7c 48 11 07 vmovups %zmm0,(%rdi)
7f73db81883f: 62 f1 7c 48 10 06 vmovups (%rsi),%zmm0
[...]
Затем вы можете легко написать небольшой скрипт python для добавления точки останова (или точки трассировки) в каждом руководстве по AVX-512. Что-то вроде
(gdb) python
>import os
>with os.popen('objdump -d core.19602 | grep %zmm0 | cut -f1 -d:') as pipe:
> for line in pipe:
> gdb.Breakpoint("*" + line)
Конечно, он создаст несколько сотен (или тысяч) точек останова. Однако накладные расходы на точку останова достаточно малы для поддержки gdb (я думаю, <1 кБ для каждой точки останова).
Другим способом было бы запустить ваш код в виртуальной машине. Тем более, я предлагаю libvex. libvex используется для динамического кода инструмента (утечка памяти, профилирование памяти и т.д.). libvex интерпретировать машинный код, перевести его в промежуточное представление и перекодировать машинный код для выполнения ЦП. Самый известный проект, использующий libvex, - valgrind (честно говоря, libvex является back-end of valgrind).
Поэтому вы можете запустить приложение с помощью libvex без каких-либо инструментов:
$ valgrind --tool=none YOUR_APP
Теперь вам нужно написать инструмент вокруг libvex, чтобы обнаружить использование AVX-512. Однако libVEX НЕ (пока) поддерживает AVX-512. Таким образом, как только он должен выполнить инструкцию AVX-512, он завершится неудачей с помощью команды "Нелегальная".
$ valgrind --tool=none YOUR_APP
[...]
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x28 0x84 0x24 0x8 0x1 0x0
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==20061== valgrind: Unrecognised instruction at address 0x10913e.
==20061== at 0x10913E: main (in ...)
==20061== Your program just tried to execute an instruction that Valgrind
==20061== did not recognise. There are two possible reasons for this.
==20061== 1. Your program has a bug and erroneously jumped to a non-code
==20061== location. If you are running Memcheck and you just saw a
==20061== warning about a bad jump, it probably your program fault.
==20061== 2. The instruction is legitimate but Valgrind doesn't handle it,
==20061== i.e. it Valgrind fault. If you think this is the case or
==20061== you are not sure, please let us know and we'll try to fix it.
==20061== Either way, Valgrind will now raise a SIGILL signal which will
==20061== probably kill your program.
==20061==
==20061== Process terminating with default action of signal 4 (SIGILL)
==20061== Illegal opcode at address 0x10913E
==20061== at 0x10913E: main (in ...)
==20061==
Примечание: этот ответ был протестирован с помощью:
#include <immintrin.h>
int main(int argc, char *argv[]) {
__m512d a, b, c;
_mm512_fnmadd_pd(a, b, c);
}