ФОРУМ ДЛЯ LINUX ПОЛЬЗОВАТЕЛЕЙ

Подготовлен релиз проекта LLVM 3.9 (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.
В новом выпуске добавлен оптимизатор ThinLTO, обеспечена совместимость с ABI libstdc++ (GCC), реализована поддержка всех возможностей OpenCL 2.0 и возможностей OpenMP 4.5, не связанных с привлечением дополнительных аппаратных вычислительных устройств, добавлен инструмент clang-include-fixer, в компоновщике lld существенно улучшена поддержка ELF и добавлена начальная поддержка LTO-оптимизаций LTO.
Основные новшества LLVM 3.9:
Компоновщик LLD доведён до рабочего состояния и теперь может связывать реальные приложения в формате ELF, включая сам LLVM и Clang, а также большинство приложений пространства пользователя FreeBSD. В LLD также добавлена поддержка оптимизации на этапе связывания (LTO) и объединение идентичных блоков кода. В дополнение к ранее поддерживаемым архитектурам x86, x86-64, MIPS, PowerPC и PPC64, добавлена поддержка ARM/Thumb, x32 ABI и MIPS N64 ABI;
Обеспечена совместимость с GCC ABI. Многие дистрибутивы Linux (Fedora, Debian, Ubuntu) перешли на использование нового GCC ABI для обхода несовместимостей с C++11 в libstdc++, что, в свою очередь, обернулось появлением несовместимостей с другими компиляторами, в том числе с Clang. В LLVM 3.9 добавлены патчи для решения возникших проблем;
Добавлена поддержка ThinLTO для выполнения оптимизации на этапе связывания, который может быть активирован при компиляции и связывании с опцией "-flto=thin". При использовании ThinLTO LTO-оптимизация разделена на три части: генерация промежуточного кода на этапе компиляции, запуск плагина Thin в компоновщике для комбинирования суммарных данных и выполнения общего анализа, и запуск бэкенда ThinLTO для применения оптимизаций в параллельном режиме;
Внесены многочисленные улучшения в бэкенды для архитектур ARM, AArch64, MIPS и PowerPC. В том числе добавлена поддержка процессоров Qualcomm Kryo, Broadcom Vulcan и Cortex-R8;
Для архитектуры x86 добавлена поддержка CPU Intel под кодовыми именами Skylake Server и Knights Landing, примечательных наличием инструкций AVX-512;
В бэкенд AMDGPU добавлена поддержка образов шейдеров OpenGL, хранилища буферов, атомарных счётчиков и вычислительных расширений шейдеров. Прекращена поддержка Mesa 11.0.x (требуется Mesa 12);
Прекращена поддержка сборочной системы autoconf в пользу CMake. Для сборки LLVM теперь требуется CMake 3.4.3 или более новая версия.
Источник, source

Oleg65 писал(а):Подготовлен релиз проекта LLVM 3.9 (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.
В новом выпуске добавлен оптимизатор ThinLTO, обеспечена совместимость с ABI libstdc++ (GCC),
...

Новость хорошая.
Только:
- и в стандартных репозиториях (развитых) дистрибутивов присутствуют пакеты того же CLang достаточно свежие (это Fedora 23): - при всех оптимизаторах, код, производимый CLang, всё ещё сильно уступает GCC по производительности.

Использовал clang в gentoo постоянно пока не перебрался на funtoo-тут оптимизация достаточна хороша и сборка gcc проходит терпимо быстро по времени и нагрузке.Проблемы в линуксе совсем не у clang при сборке,а в недостаточно чистом порой коде у исходных файлов пакетов.Пользовался я так довольно долго и естественно знаю какие -оперативно переводил сборку на gcc.Получается хороший выигрыш в скорости сборки и загрузка процессора при сборке clang существенно ниже.GCC мелкие ошибки запросто проходит-где чище код у собранных пакетов нетрудно догадаться.Ну и во фрибсд не дураки собрались совсем используя clang по умолчанию.