M
насчет того как это афектит на -0 не помню уже, но по-моему никак
Size: a a a
2020 February 27
M
M
короче все дело в спецификации с/c++ а так как llvm затачивался под него то вот и получаем
E
ща читал в каком-то баге ллвм про это, там кто-то защищал ллвм словами -x намного быстрее и не надо портить перф тем кому пофиг :D
E
к сожалению уже закрыл вкладку с ним
Т8
Возможно ли в LLVM завезти GC, чтобы C# в его IL мог компилироваться?
E
Т-34 85
Возможно ли в LLVM завезти GC, чтобы C# в его IL мог компилироваться?
возможно, разрешаю
E
в ллвм нет гц, есть просто базовая инфра для него
Т8
возможно, разрешаю
Просто странно, что Blazor работает так, как он сейчас работает. Одна виртуалка запущена под другой. Брр
M
MaxGraey
там еще вот такой совет был)
user of LLVM is operating with a different set of assumptions. If they care about nan bitpatterns, they know that they can't use LLVM for this (at least by default).
user of LLVM is operating with a different set of assumptions. If they care about nan bitpatterns, they know that they can't use LLVM for this (at least by default).
RE
Хороший совет. Я бы сказал, что те кому важны NaN bit pattern могут гореть в аду программировать на ассемблере.
E
Хороший совет. Я бы сказал, что те кому важны NaN bit pattern могут гореть в аду программировать на ассемблере.
а жвм оптимизирует x *-1 в -x ?
RE
Хз (лень сейчас смотреть), но имеет право. Там по спеке конкретные NaN pit patterns "скрыты" (так как они не portable). Более того, стандартный doubleToLongBits их даже специально маскирует и всегда возращает "канонический NaN", чтобы не утекали (но есть отдельный doubleToRawLongBits для тех, кто упорот).
RE
Bad, bad C# (но ему можно, там никто про портируемость кода особо и не парился)
E
Bad, bad C# (но ему можно, там никто про портируемость кода особо и не парился)
так а в чем bad, если он просто не оптимизирует эту операцию
E
там xor vs mul
E
всё как @maxgraey хочет
RE
Тем bad, что наружу твоего кода утекают детали реализации (через то, какие там в NaN стоят битики).