Релиз LLVM 2.9

Чего он может. менять порядок следования инструкций? которые в памяти.

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

> Во втором случае ест «прослойка» между исполняемым кодом и ЦП есть.

Где ты там увидел её?

LLVM и JIT до того как вторая отработает.

Плюсы? JIT? Выдыхай.

>> Интерпретируемый код + JIT = нативный код. По-вашему собрать и использовать - это быстрее чем сразу использовать собранное?

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

http://ru.wikipedia.org/wiki/SSA http://en.wikipedia.org/wiki/Static_single_assignment_form

http://drops.dagstuhl.de/opus/volltexte/2011/3065/pdf/9.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.4767&rep=rep1&ty... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.713&rep=rep1&type... http://www-hydra.stanford.edu/publications/JVM02.pdf

> Ну я так понял, пакет LLVM нужен как хороший компилятор. Причем тогда «Virtual Machine» в аббревиатуре???

потому что это «низкоуровневая виртуальная машина». Которая в отличие от «высокоуровневой виртуальной машины», вроде Java bytecode или CLR MSIL имеет жёстко типизированные все переменные (они же виртуальные регистры неограниченной длины). То есть, это такой ассемблер высокого уровня, в котором неограниченное количество виртуальных логических регистров (или переменных), которые мапятся (отображаются) на реальные физические регистры процессора, путём преобразования в SSA-форму. За счёт SSA-формы проще проводить статический анализ.

То есть, это виртуальная машина, которая:
1. ближе к железу и прозрачно на него отображается
2. находится внутри компилятора

Сравни, например, Elate (TaoOS) Virtual Processor Assembler: http://www.osnews.com/story/157/Tao_Group_on_ElateOS_AmigaDE_and_More http://www.osnews.com/story/459 http://www.amigahistory.co.uk/amigade.html http://www.amigahistory.co.uk/amisdk.html — там виртуальный ассемблер это ассемблер для виртуального процессора, который хорошо отображается на любой реальный. Затем писался свой рантайм для такого ассебмлера (intent) + тулкит + ОС (Elate) поверх него. Затем компилятор (vbcc) компилировал C в такой виртуальный ассемблер, который транслировался перед запуском в реальный.

То есть, это такая рантайм-версия LLVM.

А LLVM: это идея виртуального процессора из TaoOS/Elate + SSA представление + оптимизации SSA представления + поверх всего этого драйвер(обёртка-запускалка) к компилятору в виде библиотеки (компиляция в биткод) + транслятор биткода в конечный исполняемый код (ELF, COFF, Mach-o) архитектуры целевого процессора (статический линкер при сборке программы или JIT при запуске программы (man динамический линкер)).

То есть, это «более статическая» версия ассемблера виртуального процессора.

Ещё до кучи, сравни виртуальные машины Java, Lua и Inferno (Dis). Стековый vs. регистровый байткод, эффективная реализация интерпретатора или компилятора в байткод, эффективное отображение виртуальной машины на реальную. Тут виртуальная машина реализована в рантайме среды, а байткод транслируется в примитивы виртуальной машины, которые хорошо или плохо отображаются на реальный процессор, реальное железо.

см. ссылки
http://replay.waybackmachine.org/20011217201856/http://tao-group.com/2/tao/ap...

http://replay.waybackmachine.org/20011220101454/http://www.tao-group.com/2/ta... http://replay.waybackmachine.org/20011220101454/http://www.tao-group.com/2/ta... http://replay.waybackmachine.org/20011220101454/http://www.tao-group.com/2/ta... http://replay.waybackmachine.org/20011220101454/http://www.tao-group.com/2/ta... http://replay.waybackmachine.org/20011220101454/http://www.tao-group.com/2/ta...

>> тема модная и сравнительно несложная

Э. А (нормальные) компиляторы уже не одна из самых сложных тем? ;)

ну, в статьях выглядит довольно просто:

http://www.ffconsultancy.com/ocaml/hlvm/

Building a Virtual Machine using LLVM: part 1 (23rd January 2009) from the OCaml Journal.
Building a Virtual Machine using LLVM: part 2 (23rd February 2009) from the OCaml Journal.
Building a Virtual Machine using LLVM: part 3 (23rd March 2009) from the OCaml Journal.
Compiler development: part 1 (23rd June 2009) from the OCaml Journal.

> Можно сделать микрооптимизацию, хотя бы эффективнее использовать кэши, порядок выполнения команд для эффективного заполнения конвеера, улутшиить предсказание перехода Если это требует много машинного времени, то результат можно кешировать. Такой подход уже давно предагается, я о нем еще в 2000 от Бабаяна слышал

при чём тут Бабаян и 2000 год? в 2000 году уже было Elate/TaoOS и Transmeta, а бинарная компиляция это лет на 10 раньше.

А Михаэль Франц со slim binaries для Оберона — это вообще начало-середина 1990-х.

> Ну так я и хотел запускать компилятор уже на конечной машине. Не обязательно из исходников - из любого байт-кода.

из исходников можно брать tcc Фабриса Белларда http://bellard.org/tcc/ http://bellard.org/tcc/tccboot.html
там даже поддержку x86-64 прикрутили.

> Может, поделитесь тайными знаниями???

легко: http://www.llvm.org/pubs/

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

я знаю, что это идея давно разрабатывается

>Что такое компилятор, интерпретатор и JIT я и так знаю.

да ну. нечётко знаешь ведь.

Я сравнивал компиляцию кода на C++ и его использование в LLVM. Во втором случае ест «прослойка» между исполняемым кодом и ЦП есть.

и где тут прослойка?

вот смотри: ты запускаешь редактор ed и пишешь программу hello-world.x+- на таком замечательном языке x+-. если программа страшнее хелловорда, то уже есть модули: нужно парсить зависимости используемый модуль/включаемый модуль, получить текстовое описание зависимости, скормить его tsort-у из сoreutils, получить отсортированные топологической сортировкой пары prerequisites: dependencies, по ним сгенерировать makefile.
Затем запускаешь make через этот makefile. Он последовательно запускает: компилятор для сборки объектных модулей из исходников, библиотекарь для сборки статических и динамических библиотек, статический линкер для сборки исполняемого бинарника бинарника, включающего статические зависимости (статические библиотеки рантайма языка х+- и объектные модули собираемой программы).
Затем, статический линкер вставляет стабы для настройки динамическим линкером. Затем, ты запускаешь исполняемый бинарник в своём шелле. Шелл вызывает сисколл ядра exec, который в ядре реализует динамический загрузчик. Он парсит ELF формат, создаёт образ процесса в памяти ядра, создаёт запись таблицы информации о процессе и вызывает динамический линкер для заполнения стабов, вставленных статическим линкером. Динамический линкер настраивает перемещаемый код, и отображает .so библиотеки на образ процесса. Разрешает символы, с учётом версий различных ABI библиотек (info libtool).

теперь вызывается хелловорд: управление передаётся на функцию рантайма, которая подготавливает argc argv env аргументы, и запускает main откомпилированой программы. Откомпилированная программа вызывает printf, который сидит в рантайме языка, слинкованным с программой статически или динамически. printf реализуется через puts/putchar, вызывая для печати сисколл ядра write. функции рантайма вызываются в соответствии с соглашениями о вызове языка и компилятора, поэтому рантайм языка служит прослойкой, отображающей соглашения о вызове языка (ABI языка) на соглашения о вызове ядра (интерфейс сисколлов через прерывание или SYSENTER). Эта часть составляет ABI ядра, который реализуется через ABI архитектуры процессора.

вызов компилятора ccx+- helloworld.x+- -o helloworld.elf является обёрткой для вызовов ccx+- helloworld.x+- -o helloworld.o && ld helloworld.o cx+-rt.o -lccx+- -llibccx+- *ещё куча строчек* в gcc ты можешь посмотреть это всё через gcc -vvv -save-temps ... : «враппер» gcc вызывает препроцессор cpp, компилятор cc1, кодогенератор, ассемблер gas, статический линкер ld. Динамический линкер ld.so вызывается неявно при запуске бинарника ядром. Параметры между подпроцессами передаются через pipe (cм. например, ключ -pipe), все процессы запускаются последовательно в стиле POSIX: fork/exec (поэтому на альтернативной платформе, где fork/exec нету, а есть CreateProcess старт подпроцессов выполняется медленнее и они отнимают больше памяти).

вызов компилятора clang вызывает остальные компоненты не шелл-скриптом, а прямыми вызовами API библиотеки libLLVM*.so (или *.a). В итоге не делается fork/exec, библиотека постоянно сидит в памяти.

clang генерирует биткод *.ll напрямую вызовом API. Впрочем, есть драйвер-обёртка llc над препроцессором/компилятором/оптимизатором/кодогенератором/ассемблером, похожая на обёртку gcc над cpp/cc1/as/... Тут есть отдельный оптимизатор opt, статический линкер используется обычный GNUсный ld/gold. Ассемблер llmc обычно толком не использовался, потому что генерация производилась сразу из биткод через API, впрочем, это сильно зависит от компилятора. Сравни как работают clang/dragonegg/llvm-gcc/llvm-g++.

На выходе мы получаем *.ll биткод вместо объектного модуля, или *.o модуль из биткода, или ELF32/ELF64 бинарник, собранный статическим линкером, или *.a/*.so собранный библиотекарем. Если ELF, его можно сразу запустить. Если у нас на выходе *.ll биткод, его можно загрузить JIT-загрузчиком, который выполнит ту же задачу, что выполняет неявно вызываемый ядром при старте процесса динамический линкер. Такой JIT-загрузчик реализован не для всех компиляторов и языков на базе LLVM, cмотри, например, VMkit: JVM/CLR поверх LLVM.

Во втором случае ест «прослойка» между исполняемым кодом и ЦП есть.

ИТОГО, вопрос: Откуда взялась прослойка?

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

> И чем по сути динамический загрузчик, реализованный в ядре и вызывающий динамический линкер отличается от динамического JIT-загрузчика.

Тем, что ядерный загрузчик не выполняет JIT %)

> LLVM и JIT до того как вторая отработает.

ещё раз, LLVM это виртуальная машина времени компиляции. Которая транслирует входной язык в выходной (биткод виртуального процессора, затем объектный файл целевой архитектуры, затем линкером из него делается исполняемый ELF бинарник). Такая виртуальная машина есть и в GCC, это машина, которая работает с GIMPLE/GENERIC представлениями (её можно программировать например на MELT http://gcc.gnu.org/wiki/MiddleEndLispTranslator http://gcc-melt.org/) — внезапно, внутри GCC есть недолисп с кривым менеджером памяти.

Другая виртуальная машина: это кодогенератор GCC, который транслирует GIMPLE/GENERIC в RTL конкретной целевой архитектуры http://gcc.gnu.org/onlinedocs/gccint/RTL.html . Третья виртуальная машина: это ld linker scripts http://sourceware.org/binutils/docs/ld/Scripts.html , которые определяют, как из *.o файла делается ELF или COFF.

Четвёртая виртуальная машина: это динамический линкер http://en.wikipedia.org/wiki/Dynamic_linker

Пятая виртуальная машина: это динамический загрузчик, то, что вызывается через binf mthttp://en.wikipedia.org/wiki/Binfmt_misc

Эти виртуальные машины просты и примитивны, но допускают странные хаки вроде http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ — поэтому это именно виртуальные машины, а не API (в том же смысле, в каком срыв стека является фичей виртуальной Си-машины (Си-рантайм конпелятора+С соглашения о вызовах+libc), а не багом апи си-библиотеки). Это не бага, это фича.

Да, ещё есть виртуальная си-машина, которая подчиняется соглашениям вызова cdecl, и ноги у которой растут из O-кода BCPL : http://en.wikipedia.org/wiki/O-code_machine http://en.wikipedia.org/wiki/O-code http://en.wikipedia.org/wiki/BCPL , что неудивительно ибо С есть разжиревший BCPL со свистелками.


Расказывай мне теперь про прослойки и виртуальные машины, очень интересно послушать.

Бабаян с бинарной трансляцией — это очень древняя идея, древнее JIT/slim binaries. У них там DEC в этом направлении работала.

Wow! IOQuake3 LLVM raytracing patch

Кто пробовал?

> Затем, ты запускаешь исполняемый бинарник

не «затем», а с этого начнем.

Он парсит ELF формат, создаёт образ процесса в памяти ядра, создаёт...

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

...функцию рантайма, которая подготавливает argc argv env аргументы

подготавливает

Как громко нынче называют линейный парсинг строки...

Откомпилированная программа вызывает printf

Системные вызовы - они и в Африке системные вызовы. Логика же самого ELF приложения исполняется непосредственно на ЦП.

> Откуда взялась прослойка?

К.О: LLVM же. Сначала загрузчик ее грузит, а потом она уже загружает приложение. Причем, второй процесс куда тяжелее первого.

Первый раз вижу такого человека. Вроде бы, что-то знает, а порет такую чушь.

Советую почитать сначала http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C... чтоб в следующий раз не кидаться этим термином. К gcc и другим компиляторам он не имеет ни малейшего отношения. LLVM же является виртуальной машиной с байт-кодом и JIT-ом (http://ru.wikipedia.org/wiki/JIT).

clang смог собрать Qt: http://elcuco2.blogspot.com/2011/04/qt-clang-it-compiles.html

> LLVM же является виртуальной машиной с байт-кодом и JIT-ом (http://ru.wikipedia.org/wiki/JIT).

LLVM - является _так же_ и компилятором в нативный код. Команды его VM - это просто промежуточное представление.

Так я уже говорил:

http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6128623

> Так я уже говорил:

То есть ты уже понял, откуда и зачем там VM в аббревиатуре?

Ну откуда - то сразу было ясно. Просто на странице разработчиков было очень много про исполнение, JIT и т.д. и почти ничего про компиляцию, так что я подумал, они предлагают запускать приложения на Си как джавовые или дотнетовские.

> К.О: LLVM же. Сначала загрузчик ее грузит, а потом она уже загружает приложение. Причем, второй процесс куда тяжелее первого.

не грузит. Если ты берёшь helloworld.cxx/.c/.m , конпелируешь clang-ом, или берешь helloworld.d/конпелируешь ldc, то на выходе у тебя получается бинарник, который не требует подгрузки libLLVM*.a. LLVM — это библиотека, которая подгружается компилятором (Clang/ldc/Crack/Pure/HLVM/UnlandenSwallow/whatever) во время конпеляции программы. Конпелятор конпелирует в простой бинарный ELF, без лишних зависимостей, в чём ты можешь убедиться запустив ldd ./helloworld
Вот если ты возьмёшь llvmLua или Java/.Net через VMKit/Shark из IcedTea, тогда да, будет JIT загрузчик, который грузит приложение.

а ты не думай, ты просто почитай документацию. В первой же ссылке в http://llvm.org/pubs за 2011 год, и в первой же за 2002 год ясно написано, что это, зачем и как оно устроено (рядом за 2003 год — http://llvm.org/pubs/2003-05-01-GCCSummit2003.html — сравнение с gcc: gcc, llvm-gcc, dragonegg/clang, за 2004 год: обзор в целом http://llvm.org/pubs/2004-01-30-CGO-LLVM.html ).


В первой же ссылке по http://llvm.org/docs/ — Design & Overview.

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

ненене, они предлагают конпелировать Java/C++/Fortran/Ada в plain C: http://llvm.org/docs/FAQ.html#translatecxx , только тссс, а то мужыки-то не знают: http://llvm.org/docs/ReleaseNotes.html#c-be

> Советую почитать сначала http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C... чтоб в следующий раз не кидаться этим термином.

советую написать хотя бы парочку интерпретаторов/конпеляторов, и/или, посмотреть, как устроены внутри готовые, чтобы понимать что такое виртуальная машина

К gcc и другим компиляторам он не имеет ни малейшего отношения.

советую посмотреть в исходники того же GCC. Куда смотреть — я тебе написал.

>> Затем, ты запускаешь исполняемый бинарник

не «затем», а с этого начнем.

нифига себе басню сократили (c)

Системные вызовы - они и в Африке системные вызовы.

глубокомысленно.

Логика же самого ELF приложения исполняется непосредственно на ЦП.

а логика той же VM не исполняется непосредственно на ЦП?
Какая разница, виртуальная машина предназначена для непосредственного исполнения или staged virtual machine, через трансляцию в нативный код, который потом исполняется?

Например, Virtual virtual machine http://vvm.lip6.fr/overview.php и

«исполняется непосредственно на ЦП» — ты кагбэ забываешь о том, что внутри конпелятора сидит точно такая же виртуальная машина, которая и генерирует нативный код («который исполняется непосредственно на ЦП») из ненативного (который исполняется на VM).
Поэтому всякие разговоры о прослойках — если они времени конпеляции и не оказывают существенного влияния на производительность отконпелированной программы смысла не имеют. Нет этих прослоек в runtime, а есть стандартная рантайм-библиотека, которая сильно тоньше, чем та VM, которая использовалась при конпеляции.

Кроме того, считаю также глупым заявления «язык Х рулез потому что нативный», а «язык Y сакс потому что VM» без указания, замеров производительности и сравнения конкретных VM — потому что библиотека времени выполнения в конпелируемом в нативный код языке X (например, c runtime, objc runtime, Gobject runtime)  — реализует те же функции, что и виртуальная машина в языке Y (Lua VM, Dis VM, JRE и т.п.), и как для языка Х можно написать новый рантайм, с помощью которого будут исполняться программы на этом языке, так и для языка Y можно написать новую VM, которая более или менее эффективна, чем стандартная.

К примеру, если ты напишешь helloworld.с через puts или helloworld.c через printf ты получишь в первом случае код, который вызывает просто сисколл write, а во втором — интерпретатор форматной строки, который работает медленее, занимает больше кода, и имеет ограниченную функциональность (например, нет интерполяции строк как в C#: Console.WriteLine(«a={a}»,a); )

Тогда puts и printf — это два опкода виртуальной «печатающей машины». Второй реализован через первый, поэтому если можно вызвать и тот, и этот, первый эффективнее.
Внимание, вопрос. Чем виртуальная машина с двумя опкодами отличается от API библиотечного рантайма с двумя методами?

> Логика же самого ELF приложения исполняется непосредственно на ЦП.

непосредственно — не исполняется. Вот у меня ELF с GOT http://bottomupcs.sourceforge.net/csbu/x3824.htm , PLT http://bottomupcs.sourceforge.net/csbu/x3882.htm#AEN3884 . Как мне непосредственно его исполнить, не вызывая динамический линкер http://bottomupcs.sourceforge.net/csbu/x3735.htm#AEN3751 ?

Вызывается интерпретатор из соответствующей секции ELF файла: /lib/ld-linux-*.so.*

ВНЕЗАПНО, ELF файлы запускаются под ынтерпретатором! 111

The Procedure Lookup Table

Summary

You've seen the exact mechanism behind the PLT, and consequently the inner workings of the dynamic linker. The important points to remember are

Library calls in your program actually call a stub of code in the PLT of the binary.

That stub code loads an address and jumps to it.

Initially, that address points to a function in the dynamic linker which is capable of looking up the «real» function, given the information in the relocation entry for that function.

The dynamic linker re-writes the address that the stub code reads, so that the next time the function is called it will go straight to the right address.

ВНЕЗАПНО, это недоJIT!!! 1111

> ВНЕЗАПНО, это недоJIT!!! 1111

Трансляции между разными системами команд не происходит. НедоJIT такой недоJIT.

hotpatching за трансляцию не считаем? ну вот поэтому и недо

LD_PRELOAD=vm1 ./helloworld.elf
LD_PRELOAD=vm2 ./helloworld.elf

это не трансляция из «VM-helloworld» в «VM-vmX» ?
Система команд — апи функций перекрываемых символов

> это не трансляция из «VM-helloworld» в «VM-vmX» ?

Откуда мне знать, что делает vm1?

Система команд — апи функций перекрываемых символов

Бугага.

по поводу Objective C v2.0 Étoilé-евские программеры плакались

http://etoileos.com/news/archive/2009/03/31/1640/

Since GCC switched to GPLv3, Apple has been slowly migrating away from it.

Apple are no longer contributing much to the main GCC tree.

No one outside Apple contributes much to Objective-C in GCC.

Étoilé needs an Objective-C compiler.

и сейчас

http://etoileos.com/news/archive/2011/04/02/1702/

Exception handling, by the way, is something that's been reworked in clang 2.9 and the upcoming libobjc2 release. We now have proper interoperability with Objective-C++. This means that:

C++ and Objective-C exceptions can correctly propagate through each others' stack frames.

C++ catch statements can catch Objective-C objects thrown with @throw

Objective-C @catch statements can now catch Objective-C objects thrown with throw

Рад за Etoile и маководов. Кстати, Столлманово libobjс тормозило безбожно: http://etoileos.com/news/archive/2009/09/10/1744/ http://etoileos.com/news/archive/2010/04/28/2350/ http://etoileos.com/news/archive/2010/04/27/2303/ http://etoileos.com/news/archive/2007/11/10/2313/, а с оптимизациями http://etoileos.com/news/archive/2010/01/26/1518/ smalltalk через llvm / ObjC не так уж сильно и тормозит.

по поводу исключений, есть такое http://www.c-with-exceptions.org/ : http://webcache.googleusercontent.com/search?q=cache:YMmDEaBBOvwJ:www.c-with-... вот тут предлагает http://lyngvig.org/a-proposal-for-exception-handling-in-c.ashx изобрести свой calling convention.
В двух словах это напоминает Google Go:
if x:=open(...); x!=nil { ... } только уже обёрнутое в пролог/эпилог функции.
Минусы: нужно переписать standard C library. Один вариант: реализовать это в библиотеке http://cwe.sourceforge.net/ , второй вариант — в компиляторе http://sourceforge.net/projects/tcc-exceptions/

интероперабельности с исключениями С++ при этом конечно же, не будет.
А причём тут LLVM — при том, что в LLVM можно сделать свой calling convention, как например сделали в GHC LLVM backend, и реализовать такой пролог/эпилог.

http://lyngvig.org/a-proposal-for-exception-handling-in-c.ashx

The result was that the C version (which simulates the method presented) performed four times faster than the C++ test program.

К gcc и другим компиляторам он не имеет ни малейшего отношения.

советую посмотреть в исходники того же GCC. Куда смотреть — я тебе написал.

Да нету там виртуальных машин, хоть ты тресни! Исполнения приложения во время компиляции не происходит.

>>> Затем, ты запускаешь исполняемый бинарник

не «затем», а с этого начнем.

нифига себе басню сократили (c)

Да, прикинь, продвинутые люди не занимаются компиляцией приложения перед каждым запуском - они делают это при установке.

Логика же самого ELF приложения исполняется непосредственно на ЦП.

а логика той же VM не исполняется непосредственно на ЦП?

Спасибо КЭП, но конечного пользователя интересует именно логика приложения.

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

\0 (Почитай про функции виртуальной машины, прежде чем писать подобную ересь).

К примеру, если ты напишешь helloworld.с через puts

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

> Чего он может. менять порядок следования инструкций? которые в памяти.

Да. Поправьте если ошибаюсь. As a kind of proof — Роберт Лав, Linux Kernel Development, глава 10, «Ordering and Barriers» и глава 19, «Processor Ordering».

Спасибо.

>Но потом пришел гугле и опять мы слышим звуки множественных изнасилований участников рынка, теперь включая и эппле.

вот по поводу эпла я бы не стал так уж кидаться словами - доля у них приличная и даже растёт, по прибыли они сильно выше рынка, а уж про App Store и iPad я вообще молчу - там превосходство практически на порядок

Кому удалось завести libc++ ? А то у меня она компилится, а компилятор её потом не видит.

> Я сравнивал компиляцию кода на C++ и его использование в LLVM. Во втором случае ест «прослойка» между исполняемым кодом и ЦП есть.

Ну и в чем, по твоему, разница между LLVM и GIMPLE? Одинакового уровня прослойки.