P🍣
#define Array[i] unchecked(Array[i]) 😄
Size: a a a
2020 November 05
M
Блин, я бы препроцессором эти unchecked и inline с удовольствием выставил. По сути просто переключалка на всю либу.
Не стоит. Вообще аккуратнее с unchecked. Наверное вообще зря я тебе ее посоветовал. Ее нужно применять когда точно известно, что выход из-за границы массива исключен, В противном случае можно получить очень странное поведение из-за повреждения памяти
P🍣
Именно оно и происходит сейчас, да. Нужно пофиксить.
P🍣
P🍣
А как тебе идея с препроцессором подобным? Можно же миксовать в одной либе и JS и WASM.
M
В AS есть вот такая штука:
https://www.assemblyscript.org/transforms.html
https://www.assemblyscript.org/transforms.html
Вот пример как это можно исползовать: https://github.com/willemneal/visitor-as
c
Не стоит. Вообще аккуратнее с unchecked. Наверное вообще зря я тебе ее посоветовал. Ее нужно применять когда точно известно, что выход из-за границы массива исключен, В противном случае можно получить очень странное поведение из-за повреждения памяти
а у вас нет array boundary check elimination?
M
а у вас нет array boundary check elimination?
Пока нету, но будет. Для начала нужно сделать свой Middle IR. Чем я и занимаюсь. Но то еще не скоро
c
почему не MLIR? ))
PP
Потому что не LLVM :)
M
почему не MLIR? ))
Потому что MLIR еще не стабильный, и у него вообще по моему только байндинги для python сейчас имеются и то в виде тест кейсов
M
Petr Penzin
Потому что не LLVM :)
Вообще MLIR это middle IR для LLVM, поэтому он даже в репер LLVM находится
M
но если и прикручивать LLVM махину к AS то уже конечно лучше через MLIR, чем C api LLVM
M
Ну и свой Middle IR будет точно проще прикручивать к Binaryen. А это для нас сейчас в приоритете, так как мы его используем
PP
👍
PP
MLIR ориентирован на оптимизации графов (изначально для искуственного интеллекта), я лично скептично отношусь к тому что его можно к любому языку прикрутить
M
Petr Penzin
MLIR ориентирован на оптимизации графов (изначально для искуственного интеллекта), я лично скептично отношусь к тому что его можно к любому языку прикрутить
Ну они стараются его сделать так, что бы угодит требованиям Clang и Rust. Собственно он должен в теории заменить несостоявшийся CIR и растовский MIR. Но как там будет на самом деле не знаю. Меня еще пугает, что MLIR слишком много будет тащить того, чего нам не нужно, те же трасформации над тензорами например
PP
Да, в Индии небольшая компания пишет CIL, который должен подходить как для C/C++, так и дла фортрана, для flang (который уже в репо) делают FIR - и то и другое диалекты MLIR