Вышел LLVM 3.2

Высокоуровневые оптимизации?

Бородатый, небось, опять разосрется в своей рассылке.

Ну дык авторам, наверное, никто не навязывал названия под дулом, сами сглупили. «Как ты судно назовёшь...» Теперь будут спрашивать, пока не переименуют.

Все они правильно сделали. Отлично потроллили. Получился шикарный детектор идиотов. Достаточно пролистать один такой тред на ЛОРе, чтобы список кретинов пополнить.

Внутри GCC тоже полно точно такого же «байткода». \

там вначале gimple, который платформенно независим. почему же тогда llvm? потому что bsd.

почему же тогда llvm? потому что bsd.

Разрабатывали не в Беркли, а в иллинойском университете, соответственно лицензия там не BSD, а иллинойская.

Изначально это был проект одного человека, которого поддержал родной ВУЗ - ситуация, в России невозможная за пределами МКАДа и СПб. И фишками его были 1) ещё большая обобщённость, чем у GIMPLE 2) язык C++ - что позволило привлечь к разработке компиляторов огромное число новых разработчиков, при этом не подпортив жизнь сишникам в GCC 3) куча вспомогательных утилит и библиотеки для работы с разными формами байткода из любого приложения.

Короче, идеальная штука для академических исследований или обучения. Оказалась хороша и для других вещей. Лицензия второстепенна, это лишь довесок, чтобы не стеснять разработчиков вообще ничем. Хотя очевидно, что даже в таком инструменте, предназначенном исключительно для программистов, и то некоторые люди будут вести дешёвые рассуждения на тему пользователей, свободу которых ущемляет BSD.

Именно. «Это же VM, а не компилятор, значит GCC — быстрее» — каноничный результат детекции.

http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-platform-independe... - судя по этому пункту непереносимость не в LLVM-коде, а в C/C++-коде (т.е., сам код большинства программ на C/C++ явно и неявно ссылается на архитектурные особенности платформы). Я ковырялся с этим проектом несколько лет назад как раз по наводкам из интернета как о способе переносить между платформами логику без исходного кода (делал компилятор плагинов для распределённой числомолки - как раз хотелось скорости компилированного кода и переносимости интерпретируемого, нагуглил LibJIT и LLVM, решил начать с более свежего LLVM). До релиза (и поддержки всех задуманных платформ) разработка не дожила, потому у меня не было возможности столкнуться с непереносимостью LLVM-кода. Был бы рад за полезные ссылки по этому вопросу.

P.S.: И как тогда соотносится с этим PNaCl? Он специфицирует для LLVM условную архитектуру несуществующего процессора и добавляет слой трансляции из LLVM-кода для этого процессора уже в нативный код исполняющего процессора?

я немного участвую в разработке llvm, видите ли подмножество llvm ir используется для генерации кода шейдеров для amdшных видеокарт. и что я вам хочу сказать. интринсики реализуются ручками, да. но это не сложно. это оценено участниками проекта GPGPU. урезаный IR называется CPIR. размеры и alignmentы... вы печальный пользователь msvc? sizeof(int)=32, sizeof(long)=sizeof(ptr)=32 or 64 верно для многих архитектур если конечно у вас не msvc. значительная часть кода переносится легко и безболезненно.

в llvm очень много минусов, причем один из них очень-очень гадкий.

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

мне это было нужно потому что в amd щас «работают»(думают) как улучшить компилятор. я хотел было внести предложение(оптимизация кода в simd и в vliw по сути одинаковая - и там, и тут группировка команд) но без тегов это не сделать. в пределах passа я могу «предложить» как разместить данные по регистрам и команды упорядочить. но их никак не сохранить для передачи следующему passу.

кстати еще одна гадюшная особенность llvm - passы разрушают информацию о предыдущем состоянии.

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

это помогает в частности в оценке кпд шейдеров - сколько регистров они юзают, насколько эффективно их трамбуют - от этого зависит, сколько waveов можно запустить на одном compute-unitе, ибо всего 128 регистров, 3 шейдера жрущие по 40 регистров легко и безболезненно оставляют курить бамбук 7 из 10 потоков на 1 CU - для него просто негде выделить регистры.

там вначале gimple, который платформенно независим.

Чушь. Бредишь. Очень даже зависим от платформы. ABI и intrinsics уже там.

почему же тогда llvm? потому что bsd.

Чушь. Бредишь. LLVM - потому, что C++, потому, что модульность, потому, что TableGen и очень легко добавлять новые backend-ы.

размеры и alignmentы... вы печальный пользователь msvc?

Я пользователь MSP430 и MicroBlaze, а так же or1200 и некоторых платформ, о которых ты никогда не слышал и не услышишь. Для меня LLVM IR вообще никак не переносимый.

Ну и насчет alignment-а ты пойди и пропудри мозги пользователям спарков. А потом возвращайся и рассказывай, какими новыми для тебя словами они тебя обозвали.

в пределах passа я могу «предложить» как разместить данные по регистрам и команды упорядочить. но их никак не сохранить для передачи следующему passу.

Открой для себя MDNode.

это помогает в частности в оценке кпд шейдеров - сколько регистров они юзают, насколько эффективно их трамбуют - от этого зависит, сколько waveов можно запустить на одном compute-unitе, ибо всего 128 регистров, 3 шейдера жрущие по 40 регистров легко и безболезненно оставляют курить бамбук 7 из 10 потоков на 1 CU - для него просто негде выделить регистры.

Але, ты вообще откуда рухнул такой? Такие вещи надо делать на selection DAG, а вовсе не на уровне IR.

Достали бздуны тупые. Нельзя умному человеку быть таким тупым. Ну немного надо разбираться в человеческой природе. Без GPL вами корпорации подотрутся и насухо выдоят. бсд это проявление принципа раделяй и властвуй. Недаром его лидеры являются лицами традиционной для правительства США ориентации.

Достали гплбои с нытьём и попаболью. что не могут себе в ютненький мирок захапать свободный код.

Я пользователь MSP430 и MicroBlaze, а так же or1200 и некоторых платформ, о которых ты никогда не слышал и не услышишь.

повелитель мух и микроконтроллеров, не смеши мои тапочки.

пропудри мозги пользователям спарков

вообще жир какой-то. у вас походу профессиональная деформация, на все смотрите как на микроконтроллер и норовите кодить на ассемблере.

Открой для себя MDNode.

//I=old instruction, Result=new instruction
02329         if (!I->getDebugLoc().isUnknown())
02330           Result->setDebugLoc(I->getDebugLoc());
02331         // Everything uses the new instruction now.
02332         I->replaceAllUsesWith(Result);
02333 
02334         // Move the name to the new instruction first.
02335         Result->takeName(I);

Такие вещи надо делать на selection DAG, а вовсе не на уровне IR

Vertex Program Flow

The VGT receives a pointer to a buffer of vertex indices. It retrieves those indices and sends one index per vertex to SPI.

The SPI groups these into vectors called wavefronts of up to 64 vertices (size is asic dependant) in its input buffers.

When the wavefront is ready to be processed:

a. SPI allocates GPR and thread space for the Vertex Shader program to run based on driver- provided sizes

b. The indices are transferred into the GPRs in the SP

c. The shader core is then notified that a new wavefront is ready for execution

повелитель микроконтроллеров блин.

Смотрю на shootout, C код как будто более читаем чем C++. Не могу никак заинтересоваться этим C++.

Может лучше было бы к C просто добавить модульность с классами, и на этом остановиться?

Ибо мне страшно всё это читать.

Этот извечный пинг-понг с лицензиями...

Пусть хоть что-то делается и доводится до логического завершения, как Python например.

А то на данный момент всё просто куча технически интересных недоделок но под очень гордыми лицензиями Неуловимого Джо.

Пшел вон, грязная свинья. Мнение такого дерьма, как ты, вообще никого не интересует.

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

И посмотри наконец, лапоть, как сделать PTX target.

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

Ты, лапоть, не знаешь что метаданные трутся стандартными оптимизирующими проходами, но что-то там советовать пытаешься. Судя по лексике, малолетний школоло впридачу. Ребеночек, пострайся не писать больше того, чего не знаешь.

И посмотри наконец, лапоть, как сделать PTX target.

Ребеночек, еще раз повторю: не пиши незнакомые тебе слова, смысла которых ты не знаешь. невидия тоже выделяет регистры на ходу: In many programs, there is little live data in the registers while waiting for data to return from global memory. However, when the data (e.g., texture, etc.) is returned the resulting computation requires a larger number of registers. On one set of shaders the average fraction of unused register is close to 60%. The maximum number of registers required during the lifetime of the program, however, is currently what is allocated for each thread context.

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

Значит, у PTX та же проблема, что и у тебя - скопипасти их решение («Emit virtual registers»).

уважаемый, llvm не генерит нативный код для GPU, а работает в виде некоего парсера opencl и glsl. там просто нечего копипастить. у нас забирается прямо IR. невидия долго клепала лисапеды, а теперь решила сделать переходник с IR на лисапед.

кроме того, в ptx нет регистров вообще в нормальном смысле этого слова. то есть они как бы есть но их нелимитировано, что есть наололово.

и наконец, нет задачи скомпилировать. есть задача узнать сколько шейдеров стартанет «вот с такого кода». И указать узкое место. А как я его укажу, если оптимизационные проходы уничтожают метаданные?

Ты, лапоть, не знаешь что метаданные трутся стандартными оптимизирующими проходами, но что-то там советовать пытаешься.

Ну и на кой ты, лапоть, суешь «стандартные оптимизирующие проходы» между теми двумя пассами, между которыми ты пытаешься передать информацию? Все только от тебя зависит. Выбирай любую последовательность пассов, придурок.

невидия тоже выделяет регистры на ходу

Именно. Однако, придурок ты скорбный, PTX target - это полноценный target, построенный на Selection DAG, не смотря на то, что PTX - это высокоуровневая, абстрактная машина. И тебе, придурок, надо свой target делать именно на этом уровне, а не заниматься мастурбацией с IR.

IR для того, что ты пытаешься с ним делать, абсолютно не предназначен. А вот selection DAG как раз подходит. Но ты ж, ламер, бубнишь тут чего-то про какие-то идиотские регистры, тогда как это вообще не при чем.

и наконец, нет задачи скомпилировать. есть задача узнать сколько шейдеров стартанет «вот с такого кода».

Ну и как ты, убогий, вычислишь register pressure до всех оптимизаций и до кодогенерации?

И указать узкое место. А как я его укажу, если оптимизационные проходы уничтожают метаданные?

Ты это можешь сделать максимум на уровне selection DAG. И тебе придется повторить почти все то же, что делает собственно кодогенератор. Иначе все твои указки будут полнейшим, нерелевантным бредом. Сначала, идиот, register allocation, и только потом уже всякие идиотские подсказки по поводу register pressure.

О, я смотрю, наш повелитель микроконтроллеров погуглил, занялся самообразованием и снова выступает на арене цирка.

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

Жопоболь видимо была настолько сильна, что вы начали писать взаимоисключающими абзацами. ОЛОЛО.

IR для того, что ты пытаешься с ним делать, абсолютно не предназначен. А вот selection DAG как раз подходит

Совершенно внезапно для школьников перед ним стоят llvmные проходы, удаляющие метаданные. Также совершенно внезапно школьники не знают, что все оптимизации делались без учета реального железа и часть «оптимизаций»(даже в пределах одного прохода) может легко увеличивать колво требуемых регистров. В общем, вам не понять, вы же пользователь «MSP430 и MicroBlaze, а так же or1200 и некоторых платформ о которых я не знаю», и вообще, у вас жопоболь.

Сначала, register allocation, и только потом уже всякие идиотские подсказки по поводу register pressure.

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

Чувак, ты обосрался знатно. Не используй LLVM, тебе на него мозгов не хватает.

А на cuda байткод можно будет выполнить?

насколько ущербны все ide, которые вы до этого использовали.

кроме emacs, конечно.

кроме emacs, конечно.

Безусловно. Хотя я так не смог пересесть на emacs, возможно именно из-за привычки к вимовским режимам и управлению.

Что, у него от этого появится вменяемый рефакторинг?

Нет, рефакторинг руками. Во всяком случае я не знаю об автоматическом рефакторинге.

Или в подсказках будут использоваться варианты, основанные на анализе текущего контекста (типа, если в данной точке доступны переменные: локальная C1 a, глобальная C2 g_b и член класса C3 m_c, - то при написав «myFunc(», вы в подсказках получите «myFunc(a, g_b, m_c)», при условии, что myFunc принимает параметры этих типов)?

Млять, да. Устал уже повторять - clang_complete.

Или всё это нафиг не нужно, и Люк должен выключить компьютер, чтобы попасть точно в цель?

Елена Степаненко?

По теме. Мне тут товарищи из нашего отдела портирования сказали, что clang стал основным компилятором для iOS. И это при том, что бенчмарки «обычного clang vs gcc» местами пугают. У эппла в девките совсем свой clang, с ментоловым вкусом, или решили, что процессор пятого айфона надо как-то утилизировать?

При чем тут пятый ифон? Эпл давно использует clang как основной компилятор.

спустя неделю решили повторить, для верности? Я и в первый раз хорошо слышал.

Впрочем, за информацию про clang_complete я и второй раз спасибо скажу (правда, не использовал ещё), и по поводу «давно» уже тоже посмотрел, что примерно год как основной компилятор.

Но вообще, после корпоративов добрее к людям надо быть. С наступающим!

спустя неделю решили повторить, для верности? Я и в первый раз хорошо слышал.

Угу, забыл, что уже отвечал на это сообщение. Увидел его в уведомлениях, ответил.

Шесть дней назад LLVM/Clang 3.2 закоммичен в HEAD FreeBSD 10-CURRENT. Релиз FreeBSD 9.1 задерживается, видимо, из-за подготовки бэкпортирования LLVM/Clang 3.2 в 9-STABLE и последующей сборки релиза с новой версией компилятора.

LLVM/Clang 3.2 собрал libxul-10. До этого были проблемы со сборкой — пакет собирался только GCC. (Время сборки — 12 минут).

Релиз FreeBSD 9.1 задерживается, видимо, из-за подготовки бэкпортирования LLVM/Clang 3.2 в 9-STABLE и последующей сборки релиза с новой версией компилятора.

А разве в мейллистах не обсуждают подобное? Просто тогда странно, что ты их не читаешь.

Не читаю.

Не читаю.

Вопрос был - почему?

Не интересно.

Sublime Text 2 ещё.