Чому компілятори C оптимізують перемикач і якщо інакше

Нещодавно я працював над особистим проектом, коли натрапив на дивну проблему.

У дуже тісному циклі у мене є ціле число зі значенням від 0 до 15. Мені потрібно отримати -1 для значень 0, 1, 8, 9 і 1 для значень 4, 5, 12 і 13.

Я звернувся до godbolt, щоб перевірити кілька варіантів, і був здивований, що, здається, компілятор не зміг оптимізувати оператор перемикання так само, як ланцюг if.

Посилання тут: https://godbolt.org/z/WYVBFl

Код такий:

const int lookup[16] = {-1, -1, 0, 0, 1, 1, 0, 0, -1, -1, 0, 0, 1, 1, 0, 0};

int a(int num) {
    return lookup[num & 0xF];
}

int b(int num) {
    num &= 0xF;

    if (num == 0 || num == 1 || num == 8 || num == 9) 
        return -1;

    if (num == 4 || num == 5 || num == 12 || num == 13)
        return 1;

    return 0;
}

int c(int num) {
    num &= 0xF;
    switch (num) {
        case 0: case 1: case 8: case 9: 
            return -1;
        case 4: case 5: case 12: case 13:
            return 1;
        default:
            return 0;
    }
}

Я б міг подумати, що b і c дадуть однакові результати, і я сподівався, що зможу прочитати біт-хаки, щоб самостійно прийти до ефективної реалізації, оскільки моє рішення (заява переключення - в іншій формі) була досить повільною.

Як не дивно, bкомпільований на біт-хаки, в той час cяк або в значній мірі неоптимізований, або зведений до іншого випадкуa залежно від цільового обладнання.

Хтось може пояснити, чому існує ця невідповідність? Який "правильний" спосіб оптимізації цього запиту?

Редагувати:

Уточнення

Я хочу, щоб рішення комутатора було найшвидшим, або аналогічно «чистим» рішенням. Однак при компіляції з оптимізаціями на моїй машині рішення if значно швидше.

Я написав швидку програму для демонстрації, і TIO має ті самі результати, що і в мене на локальному рівні: Спробуйте в Інтернеті!

З static inlineтаблицею пошуку трохи прискорюється: Спробуйте це в Інтернеті!

Якщо ви чітко перераховуєте всі випадки, gcc є дуже ефективним:

int c(int num) {
    num &= 0xF;
    switch (num) {
        case 0: case 1: case 8: case 9: 
            return -1;
        case 4: case 5: case 12: case 13:
            return 1;
            case 2: case 3: case 6: case 7: case 10: case 11: case 14: case 15: 
        //default:
            return 0;
    }
}

просто складається в простій індексованій гілці:

c:
        and     edi, 15
        jmp     [QWORD PTR .L10[0+rdi*8]]
.L10:
        .quad   .L12
        .quad   .L12
        .quad   .L9
        .quad   .L9
        .quad   .L11
        .quad   .L11
        .quad   .L9
        .quad   .L9
        .quad   .L12
etc...

Зауважте, що якщо default:не коментується, gcc повертається до своєї вкладеної версії гілки.

Компілятори C мають особливі випадки switch, оскільки вони очікують, що програмісти зрозуміють ідіому switchта використають її.

Код типу:

if (num == 0 || num == 1 || num == 8 || num == 9) 
    return -1;

if (num == 4 || num == 5 || num == 12 || num == 13)
    return 1;

не пройшов огляд компетентними кодерами С; три-чотири рецензенти одночасно вигукували "це має бути switch!"

Компіляторам C не варто аналізувати структуру ifоператорів для перетворення в таблицю стрибків. Умови для цього повинні бути справедливими, і кількість варіацій, яка можлива в купі ifтверджень, є астрономічною. Аналіз є складним і, ймовірно, вийде негативним (як у: "ні, ми не можемо перетворити ці ifs у switch").

У наведеному нижче коді буде обчислено ваше відділення без вікна пошуку, без LUT, за ~ 3 тактових цикла, ~ 4 корисних інструкції та ~ 13 байт inlineвисокомобільного машинного коду x86.

Це залежить від цілого представлення комплементу 2.

Однак ви повинні переконатися, що u32і s32typedefs дійсно вказують на 32-бітні неподписані та підписані цілі типи. stdint.hтипи uint32_tі int32_tбули б придатними, але я не маю уявлення, чи доступний вам заголовок.

const int lookup[16] = {-1, -1, 0, 0, 1, 1, 0, 0, -1, -1, 0, 0, 1, 1, 0, 0};

int a(int num) {
    return lookup[num & 0xF];
}


int d(int num){
    typedef unsigned int u32;
    typedef signed   int s32;

    // const int lookup[16]     = {-1, -1, 0, 0, 1, 1, 0, 0, -1, -1, 0, 0, 1, 1, 0, 0};
    // 2-bit signed 2's complement: 11 11 00 00 01 01 00 00 11 11 00 00 01 01 00 00
    // Hexadecimal:                   F     0     5     0     F     0     5     0
    const u32 K = 0xF050F050U;

    return (s32)(K<<(num+num)) >> 30;
}

int main(void){
    for(int i=0;i<16;i++){
        if(a(i) != d(i)){
            return !0;
        }
    }
    return 0;
}

Побачите самі тут: https://godbolt.org/z/AcJWWf

Про підбір постійної

Ваш пошук призначений для 16 дуже малих констант від -1 до +1 включно. Кожен вміщається в 2 біти, і є 16 з них, які ми можемо викласти так:

// const int lookup[16]     = {-1, -1, 0, 0, 1, 1, 0, 0, -1, -1, 0, 0, 1, 1, 0, 0};
// 2-bit signed 2's complement: 11 11 00 00 01 01 00 00 11 11 00 00 01 01 00 00
// Hexadecimal:                   F     0     5     0     F     0     5     0
u32 K = 0xF050F050U;

Розмістивши їх з індексом 0 найближчим до найбільш значущого біта, один зсув 2*numрозмістить бітовий знак вашого 2-бітного числа в біт знаків регістра. Зсуваючи право двозначне число на 32-2 = 30 біт знак - розширює його на повне int, виконуючи трюк.

Ви можете створити той же ефект, використовуючи лише арифметику:

// produces : -1 -1 0 0 1 1 0 0 -1 -1 0 0 1 1 0 0 ...
int foo ( int x )
{
    return 1 - ( 3 & ( 0x46 >> ( x & 6 ) ) );
}

Незважаючи на те, що технічно це все-таки (розрядний) пошук.

Якщо вищезгадане здається занадто прихованим, ви також можете зробити:

int foo ( int x )
{
    int const y = x & 6;
    return (y == 4) - !y;
}