Слайды с доклада про strict-aliasing

Выступил на 57-ой научной конференции МФТИ с докладом про мой любимый strict-aliasing. Слайды можно посмотреть здесь:

Правила перекрытия объектов в памяти from Alex Markin

Наверное стоит добавить пару комментариев по теме и вообще.

Такая тема взята потому как я являюсь автором strict-aliasing в компиляторе Эльбруса. Я когда-то уже переводил статью по данной теме, но в реальности ещё не видел ни одной нормальной публикации. Хочу сделать её сам, но пока не получается.

Сам strict-aliasing разрывает зависимости между load'ами и store'ами несовместимых типов. Что такое несовместимые типы долго объяснять, скажу только что совместимы только одни и те же типы с квалификаторами и типы, вложенные в агрегатные типы.

В компиляторах реализация strict-aliasing обычно делится на две (минимум) части - оптимизационный анализ и анализ нарушений. Последний в gcc реализован на редкость плохо, мне удалось сделать анализ дающий очень мало false-positive. Я пока не замерял как gcc'шный анализ влияет на производительность, но на компилятоое Эльбруса удалось добиться прироста до 8%. При том, что в реализации есть серьёзные загрубления.

Эльбрус-8С

В МЦСТ постоянно идёт разработка новых процессоров, о которых предпочитается не заявлять публично. Но после получения хоть как-нибудь результатов разрешается что-нибудь рассказать. Относительно недавно появились инженерные образцы нового процессора Эльбрус-8С, о котором пойдёт речь.

Новый блог о компиляторах: compileit.ru

Решил попробовать запустить один проект - блог о компиляторах и языках программирования http://compileit.ru. В данном блоге я публикую ссылки на различные статьи, публикации или просто интересные новости по данной тематике. Основной целью блога (помимо сбора интересующей меня информации, конечно) является организация вокруг него русскоязычного сообщества разработчиков компиляторов и людей, интересующихся языками программирования. Мне эта задача кажется важной в первую очередь потому что сейчас отсутствует нормальный обмен информацией между различными группами исследователей/разработчиков, и ни у кого нет общей картины направления движения индустрии. Более того может получаться ситуация, что исследование, проводимое в одной группе уже было проведено в другой, опубликовано где-то, где гугл не ищет, и получается, что часть работы была проделана зря. Я надеюсь, что если исследователи и разработчики будут обсуждать свои идеи в единой площадке, то это даст мощный толчок к развитию компиляторостроения и информатики в России.

Сложности линковки

В очередной раз столкнулся с довольно забавным случаем из исходников. Что характерно это SPEC, и в нём обнаружилась ошибка (уже вторая с которой я столкнулся!). Причём для проявления ошибки должны были очень удачно сложиться звёзды.
/**
 * Это вторая редакция поста с несколько расширенным разбором случая
*/
Я не буду показывать весь SPEC, а рассмотрю только маленький примерчик.

Реализация таблиц виртуальных функций в C++

Нашёл в архивах Сети хорошую статью про реализацию таблиц виртуальных функций в C++, поэтому решил перевести. Узнал несколько крайне интересных деталей. Например, что бывает до двух реализаций одного (!) конструктора и до трёх реализаций одного (!) деструктора. Ну и ещё про то что такое VTT (virtual table table), с чего я собственно на эту статью и вышел.

llvm vs. gcc - 2014

Я уже писал про сравнение gcc и llvm в 2013 году, и вот недавно вышло сравнение свежих версий. Сравнение претерпело некоторые изменения, и разумеется, хотелось бы об этом написать.

Не все перемещения на регистр одинаково полезны

Словил забавную багу (а может и не багу) оптимизатора на казалось бы простеньком примере:

$ cat t.c
#include <stdio.h>

typedef double t;

t a = 0.5;
t b = 0.23;
t c = 6.0;

int main (void)
{
  t e, f;

  e = a - b;
  f = e * c;

  printf ("%.30f\n", f);
  return 0;
}

$ gcc t.c -O2 && ./a.out && gcc t.c && ./a.out
1.619999999999999884536805438984
1.620000000000000106581410364015


Такой эффект наблюдается с совершенно бородатых времён (ещё по-моему gcc-2.x такое выдавал). И наблюдается он только на 32-битном x86.

Сначала я думал, что это вина gcc, особенно с учётом того что llvm отрабатывает нормально. Но я эту багу нашёл в багзилле, суть вот в чём. Без оптимизации компилятор хранит double переменные на стеке, там они занимают положенные 64 бита и всё хорошо. А при включённой оптимизации он перемещает значение на плавающий регистр, который имеет размер 80 бит.

На вики есть объяснение почему именно 80 бит. Это связано с тем, что для удвоения точности экспоненту нужно увеличить на 1 бит и получить 12 бит, а мантиссу до 77 вместо старых 55 бит. Решение довольно спорное, т.к. оно не портируемое. Т.е. программе для того чтобы результат в разных режимах на разных машинах выдавал одинаковый результат нужно весьма извращаться. Иногда помогает ключ -ffloat-store, который запрещает хранить плавающие значения на регистрах.