LINUX.ORG.RU

Вышел LLVM 3.1

 


0

5

После 6 месяцев, прошедших с выпуска LLVM 3.0, представлен очередной релиз проекта LLVM 3.1. LLVM (Low Level Virtual Machine) — универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями. Может использоваться как оптимизирующий компилятор этого байткода в машинный код для различных архитектур либо для его интерпретации и JIT-компиляции (для некоторых платформ).

Некоторые изменения:

  • значительно расширена поддержка C++'11 в компиляторе Clang;
  • AddressSanitizer — инструмент для поиска ошибок работы с памятью, позволяющий обнаруживать типичные ошибки при программировании на Си и Си++, такие как выход за границы буфера и т.п.;
  • в генератор кода добавлена поддержка так называемых «связок инструкций», позволяющих значительно повысить качество генерируемого кода для архитектур процессоров VLIW;
  • улучшена работа MIPS и ARM бэкенда;
  • помимо основных функций, этот релиз включает в себя улучшение производительности, исправление ошибок и другие усовершенствования.

Напоминаю, что LLVM позволяет компилировать программы написанные на языках С, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end. В рамках проекта разработан фронтенд Clang для языков C и C++ и версия GCC, использующие llvm в качестве бэкенда. В Glasgow Haskell Compiler также реализована компиляция посредством llvm, существует ещё множество программ, использующих данную инфраструктуру.

>>> Подробности

★★★★★

Проверено: tazhate ()
Последнее исправление: thelonelyisland (всего исправлений: 2)

Ответ на: комментарий от unsigned

И чем C не соответствует этому определению?

В C не определены фундаментальные типы данных, например, строковый тип. Такие типы данных моделируются на этапе анализа и/или работы программы: строковый тип условно определяется на языке C через указатель на последовательность байтов в памяти, оканчивающуюся «нулём» — размер строки, как определяемого типа данных, неизветен компилятору.

iZEN ★★★★★
()
Ответ на: комментарий от Napilnik

Повторяйте почаще: есть данные, а есть указатели на данные, и не пользуйтесь типами для данных в адресной арифметике.

dik
()
Ответ на: Забейте. от anonymous

Ну да, там Apple использует... Где-то, как-то. Ну вот чего-то для фряхи гондобят...

Еще Intel. Еще nvidia. Еще AMD. Конечно же, ARM. А так - да, почти никто не использует, как же.

anonymous
()
Ответ на: комментарий от iZEN

Чувак, у тебя ровно 0 целых 0 десятых знаний о том, как работает компилятор C или Паскаля. Не позорься.

anonymous
()
Ответ на: комментарий от anonymous

Этих самых VM внутри самого GCC есть несколько штук.

А можно пруфы попросить? А то вот как-то не вижу в упор именно VM и именно в gcc и именно аж нескольких штук. Если Вам «показалось» что там есть что-то похожее на vm, то тогда... Ну, Вы поняли? :)))

LLVM отличается от GCC только тем, что у него эта VM одна и унифицированная, примерно идентичная GCC GIMPLE. Все остальные VM, используемые в GCC, по большому счету лишние и без них все проще, как практика llvm и показывает.

ЛОЛШТО?!? GCC GIMPLE??? Это по Вашему VM??? Батенька, да Вы, не побоюсь этого слова, фееричны нониче! :))) GCC GIMPLE это просто форма записи, которая используется при генерации кода. Настоятельно рекомендую курить intermediate representations до полного просветления сознания.

Кстати, в дальнейшем GCC GIMPLE скармливает результаты своей работы всё тому же RTL. Который пока ещё так же не является виртуальной машиной.

Я поооонял! Вас подвело хреновое знание английского. В GCC нет виртуальных машин. Там есть описание абстрактной машины. Но вещи это разные. ;) Учите матчасть. Будете более умно выглядеть. :)))

в нем много лишнего, нет очевидного и простого механизма добавления новых пассов.

А Вы их пробовали искать? Очевидные и простые. Судя по тому, что Вы тут выписываете, вряд ли.

Там это на пару порядков сложнее и извращеннее делается, чем с llvm.

А Вы пробовали это делать? Опять-таки вряд ли.

Ты тупое быдло.

И здесь вряд ли... Вряд ли я, я имею ввиду... :))) То, что Вы нахватались где-то умных слов, путая абстрактную и виртуальные машины, показывает что у Вас не диплом программиста. Скорее всего, у Вас справка о том, что Вы не дурак. Присмотритесь к той бумаге по-внимательнее? :)))

anonymous
()
Ответ на: комментарий от yurikoles

Проблема проживания большего количества памяти это банальное дублирование поставляемых с видной библиотек.

Ты хочешь сказать, набор хрюшиных 32 битных либ жрёт гигабайт оперативки? Учитывая что в постал2, гта вайсити, РО, контрстрайк 1.6 и ещё туеву кучу игр нормально гамали на 256Мб оперативы и совсем мало свопилось, бред несёшь ты.

Napilnik ★★★★★
()
Ответ на: комментарий от dik

Повторяйте почаще: есть данные, а есть указатели на данные, и не пользуйтесь типами для данных в адресной арифметике.

Мне твои указатели, кроме совсем крайних случаев, вообще использовать не нужно. Рисование указателей на каждый чих показатель сырости языка или «гениальности» программиста.

Napilnik ★★★★★
()
Ответ на: комментарий от iZEN

размер строки, как определяемого типа данных, неизветен компилятору.

Это не «определяемый» тип данных - строкового типа нет в C ни при компиляции, ни при выполнении. Это понятие только для человека.

С тем же успехом можно сказать, что в яве размер массива неизвестен компилятору. Ява теперь тоже не статично типизирована?

unsigned ★★★★
()
Ответ на: комментарий от anonymous

gcc - монстр, не модульный, не встраиваемый, в нем много лишнего, нет очевидного и простого механизма добавления новых пассов

Не вброса ради — в LLVM можно добавить фронтенд, не имея llvm source tree?

buddhist ★★★★★
()
Ответ на: комментарий от anonymous

ЛОЛШТО?!? GCC GIMPLE??? Это по Вашему VM???

Сударь, ну пора уже вправить себе мозг. Второй день уже пошел.

В контексте обсуждения CLang виртуальные машины только у Вас в голове. Clang использует внутреннее представление LLVM (код для некоторой абстрактной машины). Равно также, как GCC использует внутреннего представления GIMPLE. Основное отличие - LLVM IR более универсальный (читай удобный для использования вообще, а не только собственным компилятором).

И еще, «диплом программиста» можно маме показать, а чтоб на работу устроиться - надо собеседование пройти, на котором крайне не желательно пороть чушь.

u42
()
Ответ на: комментарий от punya

когда компилируется байткод llvm он пытается использовать расширенный набор инструкций для текущей архитектуры.

Совсем идиот? Какие параметры ему в кодогенератор передашь, то он и будет собирать.

tensai_cirno ★★★★★
()
Ответ на: комментарий от dik

Сколько пафоса! Написав

array[i]

, ты ими уже воспользовался. Ну напиши программу без массивов. ;)

Это у вас указатели нужны там где они не нужны, у нас - нет.

{$MODE FPC}
{$R+}

var
q: byte; 
s: string;

begin
s:='Указатели массиву не нужны!';
Writeln('');
for q:=1 to length(s) do write(s[q]);
Writeln('');
end.
Реализация сего действия спрятана под капотом и туда не нужно каждый раз лазить с кувалдой.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Мне вот интересно, чего вы так на LLVM наезжаете, ладно может шланг как-то не так иногда переводит в промежуточное представление LLVM, но это уже проблема самого шланга, на него нужно говорить вот плохо транслирует код, кто-то говорил что нельзя в нативный машинный код компилировать с помощью ллвм, чушь все это, компилируется спокойно, можно сначала сгенерировать ассемблерный код с помощью ллвм, а потом используя gcc или еще какой компилятор его с компилировать в исполняемый файл, а можно использовать сам ллвм (хотя я все таки через gcc компилирую, причем плюс оптимизации gcc можно использовать). Вообще ллвм интересен для тех, кто хочет написать свой компилятор, благодаря ллвм можно написать свой компилятор который по производительности выходных программ будет почти как gcc,а в некоторых случаях и быстрее! Так что я считаю ллвм очень хорошим проектом, а остальные баги, не связанные с компиляцией самого промежуточного кода ллвм, вообще проблема самих компиляторов, причем которые писались не сообществом ллвм, вон шланг Apple написали...

Int64 ★★★
()
Ответ на: комментарий от awoland

Спс, нужность рубимоциона для меня пока не совсем очевидна, и дело отнюдь не в платности.

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

Apple-ch ★★
()
Ответ на: комментарий от Int64

Мне вот интересно, чего вы так на LLVM наезжаете

Да мне он по барабану, FPC всё равно компилит быстрее и поддерживает лучшие синтаксисы, лишь бы тормозной gcc из линуксов не пропал - мне такие перемены ни к чему. У нас тут параллельная ветка флейма о пользе быстрых компиляторов и языковых фичах.

Вообще ллвм интересен для тех, кто хочет написать свой компилятор, благодаря ллвм можно написать свой компилятор который по производительности выходных программ будет почти как gcc,а в некоторых случаях и быстрее!

Вот и пиши всё что тебе интересно, разве я против?

Napilnik ★★★★★
()
Ответ на: комментарий от Atlant

Ну вот, оно не рабочее, и последние коммиты аж 20 месяцев назад были

unC0Rr ★★★★★
()
Ответ на: комментарий от Int64

Вообще ллвм интересен для тех, кто хочет написать свой компилятор, благодаря ллвм можно написать свой компилятор который по производительности выходных программ будет почти как gcc,а в некоторых случаях и быстрее!

Ну вот опять... Почти всё хорошо, а потом так жидко... Ну не надо даже вспоминать про те 1.5% случаев, в которых ваш код _может_ оказаться быстрее. А так - да: модульность+встраиваемость+jit. Для особо одарённых - различные оптимизации (имхо - только для этого и нужен «биткод»). Тех, кто вспоминает про vm, «биткод» за пределами отдельной операции компиляции и прочее «вот допишут!..» - вешать на осине предварительно посадив на кол!

yyk ★★★★★
()
Ответ на: комментарий от Napilnik

Тем не менее это нас не спасает от ошибки, которая выше обсуждалась.

{$MODE FPC}
{$R+}

var
q: byte; 
s: string;

begin
s:='Указатели массиву не нужны! Но здесь массив длиннее 255 байт, так что всегда надо помнить о том, что q - смещение от указателя и не забывать про его максимально возможное значение';
Writeln('');
for q:=1 to length(s) do write(s[q]);
Writeln('');
end.
dik
()
Ответ на: комментарий от dik

так что всегда надо помнить о том, что q - смещение от указателя и не забывать про его максимально возможное значение

Ты гонишь, ничего с q не случится.

{$MODE FPC}
{$R+}

var
q: byte; 
s: string;
a: ansistring;

begin
s:='Указатели массиву не нужны! Но здесь массив длиннее 255 байт '
 +'и всем на это пофиг потому что ограничение на длину '
 +'этого типа строки не баг а фича. '
 +'Текстовые файлы со строками >255 байт не принимают текущие версии '
 +' редакторов и компилятора но в новой кому-то приспичило это прикольное ограничение снять.';
Writeln('');
for q:=1 to length(s) do write(s[q]);
Writeln('');
a:='И да, ты перепутал паскаль с жабой - для гигабайтных строк здесь используется '+
 'другой тип строк - ansistring, представляющий собой динамический массив '+
 '- можешь писать в него хоть войну и мир'+
 ' не забывая следить за оставшимся свободным местом.';
Writeln(a);

end.

Napilnik ★★★★★
()
Ответ на: комментарий от tailgunner

Ты по теме лжешь, а я и не высказываюсь.

Тролли уже не те...

Divius ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.