The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Дэниэл Бернштейн выступил с инициативой создания Си-компилят..."
Отправлено Аноним, 22-Дек-15 19:37 
>> 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. Это контракт. Вопрос не имеет смысла.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру