Как _ReadWriteBarrier распространяется вверх по дереву вызовов?
-
23-09-2019 - |
Вопрос
Я смотрю на этот фрагмент текста в Документация для встроенного _ReadWriteBarrier Visual C++ _ReadWriteBarrier:
В предыдущих версиях компилятора Visual C ++ функции _ReadWriteBarrier и _WriteBarrier применялись только локально и не влияли на функции выше по дереву вызовов.В Visual C ++ 2005 и более поздних версиях эти функции применяются на всем пути вверх по дереву вызовов .
Я понимаю, что барьер делает внутри функции, но "вверх по дереву вызовов", по-видимому, подразумевает, что функция foo()
вызов функции bar()
могу ли я знать, bar()
содержит барьер или нет.Что на самом деле изменилось в VC2005, чтобы включить это?..соглашение о вызовах / ABI, какой-то глобальный анализ, выполняемый компилятором, или что?
Решение
Документы MS никогда не бывают хорошими, и этот документ - хороший пример этого.В _ReadWriteBarrier есть 2 части:
- указание процессору выполнить ограничение памяти (т.Е. mfence),
- указание компилятору не проводить оптимизацию в обход этого барьера.
Я подозреваю, что часть дерева вызовов ссылается на # 2.т. е.:
int x = 0;
void foo()
{
x = 7;
_ReadWriteBarrier();
x = 8;
}
Без барьера x = 7 может быть полностью удалено компилятором.С барьером это остается.Теперь, как насчет функции, которая звонки фу?
void bar()
{
x = 3; // optimized away?
foo();
x = 4;
}
Я думаю, что в прошлом x = 3, возможно, было оптимизировано (что может быть трудно для компилятора определить, разрешено это или нет), но теперь он будет корректно сохранять инструкции x = 3.
Я думаю.