не удалось оптимизировать кажущийся очевидным инвариант цикла (но волатильный классификатор сотворил магию)

Речь идет не о случайном изменчивом решении вашей проблемы — проблема глубже.

Как вы уже догадались, проблема действительно относится к «у»

Проверьте этот пример:

typedef int cell;

const cell *phys_addr = (const cell*)0x12340;

int main() {
cell y = 1;
for (int i = 0; i < 20; i++) {
for (int j = 0; j < 30; j++) {
for (int k = 0; k < 50; k++) {
const cell *subarray = (&phys_addr[i] + phys_addr[i]/sizeof(cell));
const cell *subsubarray = (&subarray[j] + subarray[j]/sizeof(cell));
y /= subsubarray[k];
}
}
}
return y;
}

Я использовал трюк с делением, чтобы избежать сложной оптимизации (gcc может оценивать все циклы и предоставлять y непосредственно в простом назначении; при использовании сложения, подстановки или умножения он также развернет самый внутренний цикл — пожалуйста, поиграйте в godbolt, чтобы посмотреть, как он выглядит)

Теперь разборка выглядит так:
https://godbolt.org/g/R1EGSb

main:
push ebp
push edi
push esi
push ebx
sub esp, 12
mov eax, DWORD PTR phys_addr
mov DWORD PTR [esp], 0
mov DWORD PTR [esp+4], eax
mov eax, 1
.L4:
mov esi, DWORD PTR [esp]
mov edi, DWORD PTR [esp+4]
mov edx, DWORD PTR [edi+esi*4]
mov DWORD PTR [esp+8], edx
shr edx, 2
add edx, esi
xor esi, esi
lea edi, [edi+edx*4]
lea ebp, [edi+200]
.L3:
mov ebx, DWORD PTR [edi+esi*4]
shr ebx, 2
add ebx, esi
sal ebx, 2
lea ecx, [edi+ebx]
add ebx, ebp
.L2:
cdq
idiv DWORD PTR [ecx]
add ecx, 4
cmp ebx, ecx
jne .L2
add esi, 1
cmp esi, 30
jne .L3
add DWORD PTR [esp], 1
mov edi, DWORD PTR [esp]
cmp edi, 20
jne .L4
add esp, 12
pop ebx
pop esi
pop edi
pop ebp
ret
phys_addr:
.long 74560

.L2 является самым внутренним циклом, поэтому код выглядит так, как ожидалось — subarray и subsubarray предварительно вычисляются ранее.

Поэтому вы можете задаться вопросом — почему, когда «у» локально, все в порядке, а когда глобально — нет.

Чтобы было ясно — «у» не должно быть объявлено в основном. Это можно сделать статичным, как это

static cell y;
const cell * __restrict__ phys_addr = (const cell*)0x12340;

или использовать пространство имен

namespace wtf{ cell y; }
const cell * __restrict__ phys_addr = (const cell*)0x12340;

и чем называется y как wtf :: y;

Все еще хорош.

Все сгущается до алиасинга. Чтобы увидеть это, давайте сначала изменим y на указатель:

typedef int cell;

cell *  y;
const cell *  phys_addr = (const cell*)0x12340;

int main() {
cell ylocal;
y = &ylocal;
for (int i = 0; i < 20; i++) {
for (int j = 0; j < 30; j++) {
for (int k = 0; k < 50; k++) {
const cell *subarray = (&phys_addr[i] + phys_addr[i]/sizeof(cell));
const cell *subsubarray = (&subarray[j] + subarray[j]/sizeof(cell));
*y /= subsubarray[k];
}
}
}
return *y;
}

Оптимизация без цикла снова ….

Можно предположить, что y и phys_addr перекрывают друг друга — запись y может изменить некоторые ячейки памяти, поэтому все словари должны быть рассчитаны с самыми последними данными (const в phys_addr означает, что только ваш указатель не должен изменять память, а не то, что он доступен только для чтения в глобальном масштабе) ,

Но если вы «пообещаете», что эти адреса не пересекаются, оптимизация вернется.

typedef int cell;

cell * __restrict__ y;
const cell * __restrict__ phys_addr = (const cell*)0x12340;

int main() {
cell ylocal;
y = &ylocal;
for (int i = 0; i < 20; i++) {
for (int j = 0; j < 30; j++) {
for (int k = 0; k < 50; k++) {
const cell *subarray = (&phys_addr[i] + phys_addr[i]/sizeof(cell));
const cell *subsubarray = (&subarray[j] + subarray[j]/sizeof(cell));
*y /= subsubarray[k];
}
}
}
return *y;
}

TL; DR;

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