>> 1. http://lxr.free-electrons.com/ident?i=OPTIMIZER_HIDE_VAR
>> Это к вопросу у gcc-only.
> И что, это уже не костыль?Нет.
>> В отличие от вас, я умею в телепатию. Моя телепатия говорит мне,
>> что вы не знаете, что такое суперскалярный процессор с внеочередным исполнением.
> Ну-ну. О великий просветитель, зачем вы вообще приплели сюда суперскалярность?
Суперскалярный процессор с внеочередным исполнением волен исполнять в произвольном порядке команды, если между ними нет барьеров или зависимостей по данным. Компилятор для суперскалярного процессора с внеочередным исполнением использует это его свойство, самостоятельно, *уже на этапе компиляции* переупорядочивая некоторые команды там, где это может быть выгодно, что потенциально может спровоцировать процессор на ещё одно переупорядочивание во время выполнения (например, из-за различного расстояния до данных, адресуемых a или b, в иерархии кэшей).
Если бы тот код писался для тривиального конвеера, в функции __crypto_memneq_16() не было бы ни одной строки OPTIMIZER_HIDE_VAR(neq);. Задача разработчиков функции — постоянное время её исполнения вне зависимости от входных данных, и часть этой задачи они решают строгим упорядочиванием составляющих эту функцию команд.
>> Ещё моя телепатия говорит мне, что вы гуманитарий:
> Хоспади, д'Артаньян, Вы?
Да.
>> вступаете в противоречие с самим собой, так как ранее вставали на
>> сторону Бернштейна в его требовании обеспечить постоянное время выполнения команд сравнения
> Аноним не читатель?
>> consider adding AES support to their instruction
>> sets. For example, a CPU could support fast constant-time
> для анонимов: специальные комманды под это дело.
> И ведь таки потом AES-NI запилили, не?
Аноним не читатель. Я понятия не имею, зачем вы приплели AES-NI в свой второй пост и повторяете здесь. Речь шла о командах сравнения. AES-NI — не команда сравнения.
>> том смысле, что является лишь указанием компилятору,
> Ну, если побочный эффект – указание, то да.
Указание — единственный эффект этой конструкции.
>> запрет компилятору переупорядочивать в сгенерированном коде команды,
>> зависимость по данным между которыми компилятору неочевидна.
> Н-да, а сколько пафоса то было.
> В первую очередь, это запрет на оптимизацию.
Набор слов.
>[оверквотинг удален]
>> return __crypto_memneq(a, b, size) != 0UL ? 1 : 0;
> т.е. получает 0 или 1.
> Я не знаю, как конкретно называется используемая техника в гцц, но тa
> же классическая "abstract interpretation" при первом же проходе засветит только на
> раз, что:
> ( как только neq != 0 => нефиг далее маятся дурью,
> можно делать ret, т.к. ответ более "не меняется").
> А так – там эдакая костыльная вставка на асме, означающая (на
> сей момент) для компилятора: "неведомая магия с neq в качестве in/out",
> оптимизировать низзя.
Эта вставка вводит фиктивную зависимость по данным между обращениями к neq. Вы правильно поняли часть её назначения: гарантировать, что сгенерированный компилятором код будет в точности, без изъятий соответствовать коду, написанному на C. Это вторая часть решения задачи обеспечения постоянного времени выполнения функции.
Однако ваше опасение справедливо лишь для случаев, когда значения аргументов a и b, а также константные смещения относительно них известны компилятору во время компиляции. На практике, в ядре таких случаев нет. Вы правильно поняли назначение конструкции, но исходите из ошибочной посылки.
> Разъясняю на пальцах:
>> __asm__ ("" : "=r" (var) : "" (var))
> Темплейт-то пустой. Просто здесь объявляется, что "neq" идет в in/out, а сам
> темплейт гцц (пока) не парсится.
Совершенно верно, это фиктивная зависимость по данным. Но предотвращает она не dead code elimination (тогда здесь было бы достаточно спецификатора volatile при объявлении neq), а переупорядочивание выражений друг относительно друга.
> А теперь, вопрос на засыпку: что будет, когда гцц/шланг научатся парсить темплейт
> – и соответсвенно "узнают" о том, что neq там не
> применяется?
> И чем это лучше UD?
gcc или clang никогда не научатся разбирать содержимое ассемблерных вставок by design. Это контракт. Вопрос не имеет смысла.