Барьер компилятора asm volatile ("" ::: «memory») Опции

[koluna]

Всем привет!

Конструкция не содержит никаких инструкций и является барьером, говорящим компилятору: “сбрось все регистры в RAM до барьера и перечитай после”.

Расскажите, пожалуйста, поконкретнее, что же делает на самом деле этот барьер помимо действий, описываемых фразой, приведенной выше.

Барьеры обеспечивают надлежащий порядок доступа к volatile переменным и не обеспечивают надлежащий порядок доступа к не volatile переменным (может происходить перебрасывание через барьер).

Почему? Что это значит?

Код

volatile x, y, z;
x = 1;
y = 2;
z = 3;

Может ли компилятор поменять порядок обращения к volatile переменным x, y, z?
Т. е., влияет ли как-нибудь volatile на порядок обращения к переменным или нет?
Насколько далеко может зайти компилятор, переставляя инструкции?

Есть ли какая-либо взаимосвязь между барьером компилятора и точками следования?

[koluna]

Ребят, кто-нибудь поделится знаниями?

[AHTOXA]

Откуда у вас такие цитаты?
Насколько я знаю, обращение к volatile переменным компилятор менять не имеет права.
А барьер этот используется для обеспечения порядка доступа к не-volatile переменным.
Приведу пример.

Код

void test(){
    enable_interrupts = 0;
    some_stuff();
    enable_interrupts = 1;
}

enable_interrupts = volatile-регистр, отвечающий за разрешение прерываний.
Без барьра компилятор делал так:

Код

void test(){
    enable_interrupts = 0;
    enable_interrupts = 1;
    some_stuff();
}

То есть, some_stuff() выполнялась при включенных прерываниях, что противоречит задумке.
Введение барьера:

Код

void test(){
    enable_interrupts = 0;
    some_stuff();
    __asm__ __volatile__ ( :::"memory");
    enable_interrupts = 1;
}

Решило проблему.
Наверное такой барьер можно считать принудительной точкой следования, но я не берусь давать чётких определений на этот счёт.

[koluna]

Откуда у вас такие цитаты?

С форума.

Насколько я знаю, обращение к volatile переменным компилятор менять не имеет права.

Я тоже так думал, но, судя по всему бывают исключения...

http://blog.regehr.org/archives/28

and also accesses to volatiles should not be reordered (with some exceptions).

http://www.nongnu.org/avr-libc/user-manual/optimization.html

memory barriers don't ensure statements with no volatile accesses to be reordered across the barrier

[AHTOXA]

Я тоже так думал, но, судя по всему бывают исключения...

Нет, менять местами обращение к volatile-переменным компилятор не имеет. Собственно, про это и написано в ссылке.
То, что сделал avr-gcc в примере с cli()/sei() - может быть просто багом avr-gcc.

[koluna]

Нет, менять местами обращение к volatile-переменным компилятор не имеет. Собственно, про это и написано в ссылке.
То, что сделал avr-gcc в примере с cli()/sei() - может быть просто багом avr-gcc.

Там еще про некоторые исключения написано

А между цитатами из первой и второй статьи вижу противоречие:

Moreover, code motion is not permitted around the barrier in either direction

memory barriers don't ensure statements with no volatile accesses to be reordered across the barrier

Интересно, какой оверхед дает использование барьера?

Сообщение отредактировал koluna - Aug 30 2014, 13:02

[AHTOXA]

Там еще про некоторые исключения написано

Про исключения из правила не менять порядок доступа к volatile-переменным? Не увидел. Где?

А между цитатами из первой и второй статьи вижу противоречие:

Я согласен с первой цитатой. Хотя пример из avr-gcc не согласуется с ней

Интересно, какой оверхед дает использование барьера?

Если посреди развесистой функции с кучей локальных переменных, которые к моменту появления барьера уже все в регистрах, то оверхед может быть приличным.

[CrimsonPig]

Расскажите, пожалуйста, поконкретнее, что же делает на самом деле этот барьер помимо действий, описываемых фразой, приведенной выше.

Тут все просто Надо немножко погуглить на предмет "memory barrier", "out of order execution", "cache coherency" На хабре был цикл очень хороших статей по этому поводу..
Где-то в этом районе:
http://habrahabr.ru/company/ifree/blog/196548/

Код

volatile x, y, z;
x = 1;
y = 2;
z = 3;

Может ли компилятор поменять порядок обращения к volatile переменным x, y, z?
Т. е., влияет ли как-нибудь volatile на порядок обращения к переменным или нет?

Самое забавное, не в том, что компилятор может нагенерить, а то, процессор может выполнять инструкции не в том порядке, в котором они лежат в памяти..

[yes]

если отвлечься от армовской (?) архитектуры, то это _compiler_barrier, а бывают еще _machine_barrier (в спарке v8 он например вставляет flush), то есть можно почитать для SPARC-а про формализацию моделей памяти TSO, PSO и т.д.
у современных х86 тоже должно быть интересно, но я не в теме

[koluna]

Самое забавное, не в том, что компилятор может нагенерить, а то, процессор может выполнять инструкции не в том порядке, в котором они лежат в памяти..

Это я знаю, но в данный момент меня интересуют более простые ситуации

В данный момент обсуждаем именно барьер компилятора.


Сообщение отредактировал koluna - Sep 1 2014, 17:52

[koluna]

http://habrahabr.ru/company/ifree/blog/196548/

Спасибо за ссылки.
Вот в этой статье вижу противоречие с этой статьей (в ней есть ссылка на официальную документацию GCC):

Надо отметить, что ассемблерные вставки __asm__ __volatile__ ( … ) также являются в некотором роде барьером для GCC/Clang: компилятор не имеет права ни выкидывать, ни перемещать их вверх/вниз по коду (об этом говорит модификатор __volatile__).

Note that even a volatile asm instruction can be moved relative to other code, including across jump instructions. [...] Similarly, you can't expect a sequence of volatile asm instructions to remain perfectly consecutive.

Видимо, в этой ситуации лучше доверять официальной документации GCC, т. е., asm volatile вставки компилятор не может выбрасывать, но может "перетаскивать" и немного оптимизировать согласно стратегии своей работы.

[AHTOXA]

Видимо, в этой ситуации лучше доверять официальной документации GCC, т. е., asm volatile вставки компилятор не может выбрасывать, но может "перетаскивать" и немного оптимизировать согласно стратегии своей работы.

Там дальше (в официальной документации) есть разъяснение, как этого избежать. (Добавить искусственную зависимость от переменной, относительно операции с которой мы не хотим, чтобы компилятор двигал asm volatile вставку.
А поскольку зависимость "memory" - самая сильная (она означает зависимость от всех переменных), то, вероятно, барьер типа asm volatile (::: "memory") компилятор передвинуть никак не может.