Векторизация с развернутым циклом

Question

Я использую intel-cc для компиляции некоторого кода C ++, и с опцией -Wall, похоже, векторизует многие мои циклы. Я работаю в предположении, что это хорошо для производительности на данный момент.

Теперь мой вопрос таков; если вместо цикла for я развернул его, то есть, например,

a[0] = b[0] + 1;
a[1] = b[1] + 1;
a[2] = b[2] + 1;

вместо

for(int i=0;i<3;++i) a[i] = b[i] + 1;

может ли компилятор все еще векторизовать этот код?

Кроме того, если я получу доступ к элементам, используя вместо них ссылки, будет ли у компилятора надежда признать, что эти два элемента эквивалентны? Э.Г.

int &x, &y, &z;
x = a[0]; y = a[1]; z = a[2];

Затем заменив a на x, y и z.

Любые ответы с благодарностью! Заранее спасибо.

Answer 1

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

for(int i=0;i<3;++i) a[i] = 1.0; // case 1
a[0] = a[1] = a[2] = 1.0;        // case 2 
a.x = a.y = a.z = 1.0;           // case 3

Сборка, созданная для случаев 2 и 3, была идентична.Это хорошо, поскольку в случае 2 компилятор дал «замечание» о копировании ссылки на временный (оператор [] переопределяется для моего класса), это подразумевает (поправьте меня, если я ошибаюсь), что компилятор правильно использует оптимизацию возвращаемых значений (RVO).

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

       .section .rodata, "a"
       .align 16
       .align 16
 _2il0floatpacket.1:
       .long   0x00000000,0x3ff00000,0x00000000,0x3ff00000
       .type   _2il0floatpacket.1,@object
       .size   _2il0floatpacket.1,16
 _2il0floatpacket.2:
       .long   0x00000000,0x3ff00000
       .type   _2il0floatpacket.2,@object
       .size   _2il0floatpacket.2,8

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

Если бы кто-нибудь мог подтвердить это, было бы здорово.