SR
слева tp 121
Size: a a a
2021 February 26
SR
122 покроет все из phase 4+
SR
кроме SIMD, который в таблице как phase 3
M
loop unrolling включили по-умолчанию в v8 хоть и как экспериментально
https://bugs.chromium.org/p/v8/issues/detail?id=11298#c9
https://bugs.chromium.org/p/v8/issues/detail?id=11298#c9
2021 February 27
TP
Господа, всем привет)
А подскажите плиз, вот llvm может компилировать свой IR в wasm. Но при этом фронтенд должен генерировать какой специальной IR, совместимый с webassembly.
Кто-нибудь знает что там за различия или где можно почитать?
А подскажите плиз, вот llvm может компилировать свой IR в wasm. Но при этом фронтенд должен генерировать какой специальной IR, совместимый с webassembly.
Кто-нибудь знает что там за различия или где можно почитать?
M
Господа, всем привет)
А подскажите плиз, вот llvm может компилировать свой IR в wasm. Но при этом фронтенд должен генерировать какой специальной IR, совместимый с webassembly.
Кто-нибудь знает что там за различия или где можно почитать?
А подскажите плиз, вот llvm может компилировать свой IR в wasm. Но при этом фронтенд должен генерировать какой специальной IR, совместимый с webassembly.
Кто-нибудь знает что там за различия или где можно почитать?
Где это вы услышали про то, что фронт генерирует какото особый llvm IR если таргет указан wasm? Это не так, LLVM IR более не менее таргет-независимый, а все различия уже проявляются во время кодогенерации llvm ir -> wasm
TP
Где это вы услышали про то, что фронт генерирует какото особый llvm IR если таргет указан wasm? Это не так, LLVM IR более не менее таргет-независимый, а все различия уже проявляются во время кодогенерации llvm ir -> wasm
Clang (который как я понимаю фронтенд) хочет чтобы ему указывали —target=wasm32
M
Там различие в основном в pass pipeline:
https://llvm.org/doxygen/WebAssemblyTargetMachine_8cpp_source.html
Некоторые проходы не применяются по сравнению с нативными таргетами, в то же время появляются специфичные только для wasm. Напримре для оптимизации и генерации теневого стека, CFGStackify, конвертация irreduceble циклов в reduceble (FixIrreducibleControlFlowPass) и т д
https://llvm.org/doxygen/WebAssemblyTargetMachine_8cpp_source.html
Некоторые проходы не применяются по сравнению с нативными таргетами, в то же время появляются специфичные только для wasm. Напримре для оптимизации и генерации теневого стека, CFGStackify, конвертация irreduceble циклов в reduceble (FixIrreducibleControlFlowPass) и т д
M
Clang (который как я понимаю фронтенд) хочет чтобы ему указывали —target=wasm32
Ну логично. А как еще указывать платформу? точно так же нужно делать если нужно скомпилировать для linux и arm, Там будет так например:
а вы в тоже время на виндовсе с интелом
—target=arm-linux-gnueabihfа вы в тоже время на виндовсе с интелом
TP
Ну логично. А как еще указывать платформу? точно так же нужно делать если нужно скомпилировать для linux и arm, Там будет так например:
а вы в тоже время на виндовсе с интелом
—target=arm-linux-gnueabihfа вы в тоже время на виндовсе с интелом
Мне просто казалось, что IR все-таки должен быть платформо-независимым.
То есть я пишу
А потом полученный IR уже компилирую с помощью llc на нужную платформу
То есть я пишу
clang -emit-llvm hello.c
А потом полученный IR уже компилирую с помощью llc на нужную платформу
TP
Но видимо я ошибался)
M
Мне просто казалось, что IR все-таки должен быть платформо-независимым.
То есть я пишу
А потом полученный IR уже компилирую с помощью llc на нужную платформу
То есть я пишу
clang -emit-llvm hello.c
А потом полученный IR уже компилирую с помощью llc на нужную платформу
Вся идея IR как раз в том, что бы выделить независимое от фронта и низкоуровневого бекенда def-use представление в котором проводить разного рода анализ и проеобразования)
TP
Вся идея IR как раз в том, что бы выделить независимое от фронта и низкоуровневого бекенда def-use представление в котором проводить разного рода анализ и проеобразования)
Но тем не менее фронту надо указывать таргет чтобы он смог сгенерировать правильный IR?
M
Но тем не менее фронту надо указывать таргет чтобы он смог сгенерировать правильный IR?
Не фронту а бэку.
TP
Не фронту а бэку.
Но clang это фронт?
M
IR будет во всех случаях более не менее одинаковый
M
target - это уже хинт для самой последней стадии - кодогенерации из IR в целевое представление (.wasm или машинный код + рантайм для конкретной OC)
M
Но clang это фронт?
Да это фронт, именно поэтому он предоставляет и дальше делегирует конфиг для бека и кодогенерации
DM
Тут путаница поведения консольной команды clang и компилятором. Тебя же не смущает, что вызвав clang на выходе получаешь a.out, а не IR
TP
Кажется я нашёл ответ на свой вопрос)