Почему инструкции SSE сохраняют верхние 128-битные регистры YMM?

Question

Кажется, что многие процессоры Intel (вплоть до Skylake, если я ошибаюсь) демонстрируют низкую производительность при смешивании инструкций AVX-256 с инструкциями SSE.

В соответствии с Intel's documentation это вызвано инструкциями SSE, которые определены для сохранения верхних 128 бит регистров YMM, поэтому, чтобы иметь возможность экономить электроэнергию, не используя верхние 128 бит данных данных, центральный процессор сохраняет эти биты при выполнении кода SSE и перезагружает их при вводе кода AVX, а магазины и нагрузки стоят дорого.

Однако я не могу найти очевидной причины или объяснения, почему SSE-инструкции необходимы для сохранения этих верхних 128 бит. Соответствующие 128-битные инструкции VEX (использование которых позволяет избежать снижения производительности) работают, всегда очищая верхние 128 бит регистров YMM, а не сохраняя их. Мне кажется, что когда Intel определила архитектуру AVX, в том числе расширение регистров XMM в регистры YMM, они могли бы просто определить, что инструкции SSE также очистят верхние 128 бит. Очевидно, что поскольку регистры YMM были новыми, не могло существовать никакого устаревшего кода, который бы зависел от инструкций SSE, сохраняющих эти биты, и мне также кажется, что Intel могла легко увидеть это.

Итак, по какой причине Intel определила инструкции SSE для сохранения верхних 128 бит регистров YMM? Это когда-нибудь полезно?

Answer 1

Для перемещения внешних ресурсов на месте я извлек соответствующие абзацы с the link Michael provided in the comments.

Все кредиты идут ему.
Ссылка указывает на очень похожий вопрос, заданный Agner Fog на форуме Intel.

[Туман в respone для ответа от Intel] Если я правильно Вас понял, вы решили, что необходимо иметь две версии всех инструкций 128-битных, чтобы избежать разрушив верхнюю часть YMM регистры, если прерывание вызывает драйвер устройства с использованием устаревших инструкций XMM.

Intel были обеспокоены тем, что, делая унаследованных SSE инструкции обнуления верхнюю часть XMM регистров ЗРМС бы теперь вдруг влияют на новый YMM регистры.
Без поддержки для сохранения нового контекста YMM это сделало бы невозможным использование AVX при любых обстоятельствах .

Однако Fog не был полностью удовлетворен и указал, что, просто перекомпилировав драйвер с помощью AVX-компилятора (так, чтобы использовалась инструкция VEX ), результат будет таким же.

Intel ответила, что их цель состояла в том, чтобы не заставлять существующее программное обеспечение переписать.

Мы не можем заставить отрасль переписывать/исправлять все существующие драйверы (например, использовать XSAVE) и не гарантируем, что они сделали бы это успешно. Рассмотрим, например, боль, которую отрасль все еще переживает при переходе от 32 до 64-битных операционных систем! Отклики, которые мы получаем от поставщиков ОС, также препятствовали добавлению накладных расходов на обслуживание ISR для добавления накладных расходов на управление на каждом прерывании.Мы не хотели накладывать ни одну из этих затрат на части отрасли, которые обычно даже не используют широкие векторы.

Имея две версии инструкций, поддержка AVX драйверов может быть достигнуто, как это было для FPU/SSE:

Данный пример аналогичен текущему сценарию, где кольцо- 0 (ISR) пытается использовать состояние с плавающей запятой или случайно связывает его в некоторой библиотеке в ОС, которые автоматически не управляют этим контекстом в Ring-0. Это хорошо известный источник ошибок, и я могу только предложить следующее:

• На этих операционных систем, разработчики драйверов не рекомендуется использовать с плавающей точкой или AVX

• разработчики драйверов следует поощрять, чтобы отключить аппаратные функции во время проверки водителя (т.е. AVX состояние можно отключить с помощью драйверов в Ring-0 через XSETBV()

Answer 2

Справочная информация: решение было принято рано делать KeSaveFloatingP ointState ничего не делает на Windows x64 и позволяет использовать XMM-регистры без дополнительных вызовов для восстановления/восстановления даже в драйверах. Очевидно, что эти драйверы не будут знать о регистрах AVX или YMM.