Задний план

Это было вдохновлено этим вопросом / ответом и последующим обсуждением в комментариях: Является ли определение «изменчивого» этим изменчивым, или GCC имеет некоторые стандартные проблемы соответствия?. Основываясь на чужой и моей интерпретации того, что должно происходить, как обсуждалось в комментариях, я отправил это в GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71793 Другие соответствующие ответы по-прежнему приветствуются.

Кроме того, этот поток с тех пор вызвал этот вопрос: Предоставляет ли доступ к объявленному энергонезависимому объекту через изменчивую ссылку / указатель изменчивые правила при указанном доступе ?

вступление

Я знаю, что volatile - это не то, что думает большинство людей, и что это гнездо змей, определяемое реализацией. И я, конечно, не хочу использовать приведенные ниже конструкции в каком-либо реальном коде. Тем не менее, меня совершенно сбивает с толку то, что происходит в этих примерах, поэтому я буду очень признателен за любые разъяснения.

Я предполагаю, что это связано либо с очень тонкой интерпретацией Стандарта, либо (что более вероятно?) Просто с крайними случаями для используемого оптимизатора. В любом случае, хотя это скорее академический, чем практический, я надеюсь, что это будет полезно для анализа, особенно с учетом того, насколько часто это неправильно понимается volatile. Еще несколько точек данных - или, что более вероятно, указывают против - должны быть хорошими.

Вход

Учитывая этот код:

#include <cstddef>

void f(void *const p, std::size_t n)
{
    unsigned char *y = static_cast<unsigned char *>(p);
    volatile unsigned char const x = 42;
    // N.B. Yeah, const is weird, but it doesn't change anything

    while (n--) {
        *y++ = x;
    }
}

void g(void *const p, std::size_t n, volatile unsigned char const x)
{
    unsigned char *y = static_cast<unsigned char *>(p);

    while (n--) {
        *y++ = x;
    }
}

void h(void *const p, std::size_t n, volatile unsigned char const &x)
{
    unsigned char *y = static_cast<unsigned char *>(p);

    while (n--) {
        *y++ = x;
    }
}

int main(int, char **)
{
    int y[1000];
    f(&y, sizeof y);
    volatile unsigned char const x{99};
    g(&y, sizeof y, x);
    h(&y, sizeof y, x);
}

Вывод

g++ из gcc (Debian 4.9.2-10) 4.9.2 (Debian stable a.k.a. Jessie) с помощью командной строки g++ -std=c++14 -O3 -S test.cpp создает приведенный ниже ASM для main(). Версия Debian 5.4.0-6 (текущая unstable) производит эквивалентный код, но я просто случайно запустил сначала старую, так что вот она:

main:
.LFB3:
    .cfi_startproc

# f()
    movb    $42, -1(%rsp)
    movl    $4000, %eax
    .p2align 4,,10
    .p2align 3
.L21:
    subq    $1, %rax
    movzbl  -1(%rsp), %edx
    jne .L21

# x = 99
    movb    $99, -2(%rsp)
    movzbl  -2(%rsp), %eax

# g()
    movl    $4000, %eax
    .p2align 4,,10
    .p2align 3
.L22:
    subq    $1, %rax
    jne .L22

# h()
    movl    $4000, %eax
    .p2align 4,,10
    .p2align 3
.L23:
    subq    $1, %rax
    movzbl  -2(%rsp), %edx
    jne .L23

# return 0;
    xorl    %eax, %eax
    ret
    .cfi_endproc

Анализ

Все 3 функции встроены, и обе, которые выделяют volatile локальных переменных, делают это в стеке по довольно очевидным причинам. Но это почти единственное, что они разделяют ...

• f() обеспечивает чтение из x на каждой итерации, предположительно из-за volatile, но просто сбрасывает результат в edx, предположительно потому, что пункт назначения y не объявлен volatile и никогда не читается, что означает изменения в нем. может быть отклонено правилом как если бы. ОК, имеет смысл.

  • Well, I mean... kinda. Like, not really, because volatile is really for hardware registers, and clearly a local value can't be one of those - and can't otherwise be modified in a volatile way unless its address is passed out... which it's not. Look, there's just not a lot of sense to be had out of volatile local values. But C++ lets us declare them and tries to do something with them. And so, confused as always, we stumble onwards.

• g(): Что. Перемещая источник volatile в параметр передачи по значению, который по-прежнему является еще одной локальной переменной, GCC каким-то образом решает, что это не так или меньше volatile, поэтому ему не нужно читать его на каждой итерации ... но он по-прежнему выполняет цикл, несмотря на то, что его тело теперь ничего не делает.

• h(): при использовании переданного volatile в качестве передачи по ссылке восстанавливается то же эффективное поведение, что и для f(), поэтому цикл выполняет volatile чтения.

  • This case alone actually makes practical sense to me, for reasons outlined above against f(). To elaborate: Imagine x refers to a hardware register, of which every read has side-effects. You wouldn't want to skip any of those.

Добавление #define volatile /**/ приводит к тому, что main() не работает, как и следовало ожидать. Итак, когда он присутствует, даже в локальной переменной volatile что-то делает ... Я просто не знаю, что в случае g(). Что, черт возьми, там происходит?

Вопросы

• Why does a local value declared in-body produce different results from a by-value parameter, with the former letting reads be optimised away? Both are declared volatile. Neither have an address passed out - and don't have a static address, ruling out any inline-ASM POKEry - so they can never be modified outwith the function. The compiler can see that each is constant, need never be re-read, and volatile just ain't true -
  • so (A) is either allowed to be elided under such constraints? (acting as-if they weren't declared volatile) -
  • и (B) почему упускается только один? Некоторые volatile локальные переменные больше volatile, чем другие?
• Отбросим на мгновение эту несогласованность: почему после того, как чтение было оптимизировано, почему компилятор все еще генерирует цикл? Ничего не делает! Почему оптимизатор не игнорирует это как если бы цикл не был закодирован?

Это странный случай из-за порядка оптимизации анализа или чего-то подобного? Поскольку код - глупый мысленный эксперимент, я бы не стал наказывать GCC за это, но было бы хорошо знать наверняка. (Или это g() ручной цикл синхронизации, о котором люди мечтали все эти годы?) Если мы придем к выводу, что ни на что из этого не влияет Стандарт, я перенесу его в их Bugzilla только для их информации.

И, конечно же, более важный вопрос с практической точки зрения, хотя я не хочу, чтобы это затмило потенциал компьютерных фанатиков ... Какие из них, если они есть, являются четко определенными / правильными согласно Стандарту?