Рубрика «LLVM»

Развенчиваем популярные мифы и заблуждения о компиляторах - 1

▍ Введение

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

Эта статья станет своего рода продолжением статьи о компиляторных оптимизациях. Я перечислю некоторые заблуждения, с которыми я сталкивался за долгие годы (многие из них были моими), и постараюсь развеять все мифы. Заранее скажу, что эта статья посвящена только крупным популярным компиляторам общего назначения наподобие LLVM, GCC и ICX. Некоторые из сделанных здесь утверждений не относятся, например, к специализированным компиляторам2, а также к мелким и средним компиляторам3.Читать полностью »

Дрю ДеВолт — автор языка Hare и платформы кодохостинга SourceHut - 1Дрю ДеВолт объясняет, что веб-интерфейс Github.com требует множества лишних действий. Гораздо эффективнее использовать консольный почтовый клиент, отправляя тот же пулл-реквест одной командой из консоли

Американский разработчик Дрю ДеВолт (Drew DeVault) известен как создатель и исполнительный директор платформы для хостинга проектов SourceHut, которую Фонд сохранения свободы ПО выбрал как альтернативу майкрософтовскому сервису GitHub (наряду с CodeBerg) в рамках кампании Give Up GitHub по уходу свободных проектов с этого коммерческого хостинга, задача которого — генерировать продажи Copilot.

ДеВолт также известен как автор нового языка системного программирования Hare, который похож на С, только лучше и проще его.Читать полностью »

Уильям Фрайт Пауэлл. Бедность и богатство [1888]. (модифицированная)

Уильям Фрайт Пауэлл. Бедность и богатство [1888]. (модифицированная)

Всем привет! Сейчас за окном осенние деньки 2024 года. Вещает Пройдаков Евгений. Сейчас я руковожу группой разработки среды исполнения языка eXtraction and Processing в R&D департаменте Positive Technologies.

Читать полностью »

Undefined behavior (UB) — боль, знакомая каждому разработчику со стажем; эдакий «код Шредингера», когда не знаешь, правильно тот работает или нет. К счастью, стандарты языка С++20/23/26 привнесли относительно неопределенного поведения кое-что новое. И довольно важное, если вы — архитектор ПО, а «плюсы» — ключевой стек вашей компании (подробнее о том, как и почему мы в «Лаборатории Касперского» много используем С++, читайте здесь).

В этой статье я со своих позиций Senior Software Architect и Security Champion в микроядерной операционной системе KasperskyOS рассмотрю кейсы-ловушки, в которые можно попасть практически в любом из стандартов, и покажу, что меняется в С++20/23/26, — уменьшается ли количество кейсов с неопределенным поведением, и становится ли С++ безопаснее.

Опасность устарела: несколько важных нюансов в новых стандартах C++ - 1
Читать полностью »

Передавать пустые срезы между Rust и C-C++ на удивление сложно - 1


Моя основная работа связана с браузерами и криптографией, а не компиляторами. Но я нередко сталкиваюсь с ситуацией, когда мне приходится проводить больше рабочего времени за изучением семантики языков программирования, чем за фактическим их использованием. Так что эта статья будет посвящена обсуждению острой межязыковой проблемы, касающейся С, С++ и Rust.

В общих чертах она выглядит так:

  • В правила работы с указателями и memcpy в С не заложены грамотные способы представления пустого среза памяти.
  • В С++ с правилами указателей проблем нет, но поведение memcpy здесь аналогично её поведению в С.
  • Интерфейс внешних функций (Foreign Function Interface, FFI) в Rust не лишён накладных издержек. Rust использует несовместимое с C/C++ представление срезов, требуя их преобразования при передаче в обоих направлениях. При этом о преобразовании очень легко забыть.
  • Срезы в Rust также несовместимы с арифметикой указателей, что создаёт проблемы в работе итератора срезов стандартной библиотеки. (Обновление от 2024-01-16: похоже, над этой проблемой работают).

Поскольку проблемы FFI касаются нескольких языков, я писал статью в качестве общей справки, описывающей их несогласованность. Читать полностью »

Это цикл статей об оптимизирующих компиляторах вообще и LLVM в частности. Смотри все статьи данного цикла:

  1. SSA форма

  2. Доминирование

  3. Неопределённое поведение

  4. Циклы

  5. CSE

В этой статье мы поговорим о классе оптимизаций, которые позволяют избегать лишних вычислений при помощи переиспользования уже имеющихся результатов, а именно -- оптимизации семейства CSE. В разном виде такие оптимизации есть практически во всех известных компиляторах.Читать полностью »

Это цикл статей об оптимизирующих компиляторах вообще и LLVM в частности. Смотри все статьи данного цикла:

  1. SSA форма

  2. Доминирование

  3. Неопределённое поведение

Вообще-то, третья статья данного цикла должна была рассказывать о конкретных оптимизациях. Но пока я прикидывал её план, стало ясно, что без освещения некоторых аспектов неопределённого поведения многое из дальнейших описаний будет непонятно. Поэтому сделаем ещё один осторожный шаг, прежде, чем окунаться в омут с головой.

Читать полностью »

Сегодня мы продолжаем наш разговор об оптимизирующих компиляторах для самых маленьких и не очень. Для тех, кто пока не в курсе происходящего, но желает приобщиться - я поставил себе задачу написать цикл вводных статей в эту область для совсем-совсем начинающих. Первую часть, где рассказывается об SSA-форме, можно и нужно прочитать здесь.

Сегодня мы поговорим о доминировании. Это одна из фундаментальных вещей, на которых стоит как теория компиляторов вообще, так и многие компиляторные оптимизации в частности. Пристегните ремни и запишите стоп-слово на бумажке, чтобы не забыть.

Читать полностью »

В предыдущих статьях мы рассмотрели и реализовали лексический и синтаксический анализаторы, а так же реализовали семантический анализ для нашего учебного языка, что дало нам основу. В данной статье мы продолжим начатое и реализуем генерацию кода для LLVM IR.

LLVM

Читать полностью »

В предыдущей статье мы закончили на том, что мы написали лексический и синтаксический анализаторы для нашего учебного языка. В данной статье мы продолжим начатое и рассмотрим следующую стадию анализа исходного кода программы — семантический анализ.

Семантический анализ

Основная задача семантического анализа заключается в проверки того, что программа корректна с точки зрения языка, например:

  1. Все переменные в программе объявлены;

  2. Все выражения совершаются над корректными типами;

  3. Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js