Каково поведение __faststorefence? - PullRequest
6 голосов
/ 26 июня 2011

По этому вопросу меня интересуют только x86 и x86-64.

Для MSVC 2005 документация для __faststorefence гласит: "Гарантирует, что каждый предыдущий магазин будет виден глобально перед любым последующим магазином ."

Для MSVC 2008 и 2010 он изменился на: "Гарантирует, что каждая предыдущая ссылка на память , включая ссылки на загрузку и хранение , будет видна глобально перед любой последующей ссылкой на память . «

То, как написано последнее, на мой взгляд, подразумевает, что это также блокирует переупорядочение загрузки ЦП перед старыми магазинами. Это отличается от первого определения, которое подразумевает, что внутреннее свойство имеет дело только с блокировкой или переупорядочением невременных хранилищ с более старыми хранилищами (единственное другое переупорядочение x86 (-64) делает).

Однако тогда документация, по-видимому, противоречит самой себе: "На платформе x64 эта процедура генерирует инструкцию, которая быстрее store fence , чем инструкция sfence . Используйте эту встроенную функцию вместо _mm_sfence на платформе x64. "

Это подразумевает, что он по-прежнему имеет функциональность, подобную sfence, и, следовательно, нагрузки могут быть переупорядочены в более старых магазинах. Так что это? Может кто-нибудь прояснить мою путаницу?

PS: в поисках GCC-версии этой функции я наткнулся на long local; __asm__ __volatile__("lock; orl $0, %0;" : : "m"(local));, но я думаю, что это из 32-битного кода; какой будет 64-битный аналог?

1 Ответ

2 голосов
/ 27 июня 2011

Указанная вами версия GCC эквивалентна коду, который генерирует MSVC. Он основан на том факте, что в документах по архитектуре процессора x86 / x86-64 указано, что загрузка и сохранение не переупорядочиваются с помощью инструкции LOCK ed.

Мне не ясно, относится ли это к невременным хранилищам, поскольку в целом ограничения модели памяти не применяются к этим инструкциям.

...