E
это правда векторная инструкция, но смысл тот же
Size: a a a
2019 September 21
E
если я правильно понял - если у меня первый бит (знаковый) - 1, то считаем сколько единичек подряд идет слева, иначе - lzcnt
E
буду надеятся что если напишу
lzcnt(x ^ (x >> 1)) - 1 llvm за меня додумает что это clsS
Шикарная статься . Взахлёб читал
SS
Шикарная статься . Взахлёб читал
Андрей Николаевич - рассказчик великолепный.
E
из доков LLVM:
In practice, however, dereferencing a null pointer is extremely rare in well-behaved Java programs
E
будь well-bahaved
AS
Похоже на апологию UB около дереференса нуля.
AS
А, это про implicit null checking -- да, это мощь. В подавляющем большинстве случаев нулл-чеков не видать на горячих путях в сгенерированном коде.
E
А, это про implicit null checking -- да, это мощь. В подавляющем большинстве случаев нулл-чеков не видать на горячих путях в сгенерированном коде.
ага, внедрили у себя
E
еще где надо обмазали @llvm.expect
E
и бранч weigths
AS
без деопта? или я плохо помню, и вы таки прикрутили деопт?
E
без
E
просто будет сложный и медленный fault case
AS
Ну, э. Ок. Прагма-то есть какая-нибудь, чтобы можно было сказать, что вот тут может и null быть?
E
ты имеешь ввиду кейсы, где наллреф - это часть логики и может часто случатся?
AS
Да. Не всякий нулл-чек ведёт к исключению (там можно было бы и забить на перф плохого случая).
E
Да. Не всякий нулл-чек ведёт к исключению (там можно было бы и забить на перф плохого случая).
да, мы оптимизируем только те налл чеки, на которые вешаем метадату make.implici
E
т.е. те которые сами и генерим (а не юзер)