Что именно происходит, когда процессор Skylake неправильно предсказывает ветку?
Я пытаюсь подробно понять, что происходит с инструкциями на разных этапах конвейера ЦП Skylake, когда ветка неверно предсказана, и как быстро могут начать выполняться инструкции из правильного места назначения ветки.
Итак, давайте пометим два пути кода здесь красным (один предсказанный, но на самом деле не принятый) и зеленым (один взятый, но не предсказанный). Поэтому возникают вопросы: 1. Как далеко должен пройти ветвь, прежде чем красные команды начнут отбрасываться (и на какой стадии (ях) конвейера они отбрасываются)? 2. Как скоро (с точки зрения стадии конвейера, достигнутой ветвью) зеленые инструкции могут начать выполняться?
Я просмотрел документы Агнера Фогга и многочисленные комплекты лекционных заметок, но не нашел ясности по этим вопросам.
1 ответ
Модуль выполнения ветвления (на портах 0 и 6) - это то, что фактически проверяет FLAGS или адрес косвенного ветвления для условных или косвенных ветвлений. Я думаю, что восстановление начинается, как только исполнительное подразделение обнаруживает его, не дожидаясь выхода на пенсию. (Отчасти это мое лучшее предположение / понимание, не обязательно подкрепленное руководством по оптимизации Intel.)
Предсказание ветвлений + спекулятивное выполнение отделяет зависимости данных от управляющих зависимостей, но сама ветвь UOP действительно имеет зависимость данных от EFLAGS или косвенного ввода адреса.
Единица ветвления на p0 может запускать только предсказанные, но не принятые операции JCC (или операции с макросом JCC), но они распространены. Единица ветвления на p6 является "главной", которая обрабатывает взятые ветки.
Для прямых веток (jmp rel8/rel32 / call rel32), предсказание может быть проверено при декодировании и повторном управлении этапами выборки, возможно, остановит интерфейс, но я думаю, что никогда не нужно запускать какое-либо восстановление в серверной части. Мопы с неверного пути никогда не будут выдаваться для прямых безусловных веток. Есть перфорированные счетчики для переадресации трубопровода.
Ошибочные прогнозы ветвления быстро восстанавливаются с помощью буфера порядка ветвления, в отличие от обычного отката в состояние выхода на пенсию для исключений: когда происходит прерывание, что происходит с инструкциями в конвейере?, Для получения дополнительной информации о том, как конвейер рассматривает все как спекулятивные до выхода на пенсию, см. Выполнение вне очереди или спекулятивное выполнение.
Согласно записи о микроархе Дэвида Кантера "Сэндибридж":
Nehalem улучшил восстановление после ошибочных прогнозов в ветвях, которые были перенесены в Sandy Bridge. Как только ошибочное предсказание ветви обнаружено, ядро может возобновить декодирование, как только будет известен правильный путь, в то же время, когда машина, вышедшая из строя, очищает мопы от неверно спекулированного пути. Ранее декодирование не возобновлялось до тех пор, пока конвейер не был полностью очищен.
Это "быстрое восстановление", включаемое буфером порядка ветвления, который снимает состояние переименования в условных и непрямых инструкциях ветвления, которые, как ожидается, неверно прогнозируются даже в обычных программах. Но исключения и очистка машин упорядочения памяти стоят дороже. Они случаются (особенно ошибки страниц), но их реже и их сложнее оптимизировать.
Ключевым моментом быстрого восстановления является то, что мопы из ранее ошибочно предсказанной ветви, которые уже находятся в ROB + RS (планировщик), могут продолжать выполняться, пока последующие мопы сбрасываются, а внешний интерфейс перенаправляется на правильный адрес. Таким образом, если входные данные для UCC UOP готовы достаточно рано, большая часть штрафа за пропуск ветвления может быть скрыта, если существует длинная цепочка зависимостей, которую ЦП может жевать при восстановлении. Например, ошибочный прогноз при выходе из цикла с цепочкой приличной длины, переносимого цепочкой dep, или любое узкое место, отличное от общей пропускной способности UOP или узкого места в порту 6. См. Избегайте останова конвейера, вычисляя условно рано
Я думаю, что без быстрого восстановления все мопы в ROB будут сброшены (т. Е. Все мёртвые мертвецы). Здесь может быть что-то среднее, например, сохранение уже выполненных мопов до ветки, которая была в ROB, но покинула планировщик. Я не знаю, что именно сделали Мером / Конроу.
Связанный: Характеристика ошибочного предсказания ветвления Штраф - интересная статья о том, как пропуски ветвей и долгих кешей взаимодействуют с ROB. Он основан на упрощенной модели конвейера, но мне кажется, что его выводы, вероятно, применимы к Skylake.