|60,130 ms||x64 debian > AddressSanitizer-x86_64-linux.TestCases::scariness_score_test.cpp|
Script: -- : 'RUN: at line 4'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m64 -O0 /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/asan/TestCases/scariness_score_test.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/scariness_score_test.cpp.tmp
Hello everyone. @gonglingqin is another engineer from Loongson. Please help to review her patches. Thanks.
Are we better off handling this by just hard-coding the bit patterns then movgr2fr.w and movgr2frh.w? I don't know the exact latencies for fcvt.d.s but plain moves should be a bit faster.
nit: "will be added later"
Suggest to remove useless blank lines and indent.
lu52i.d $a0, $zero, 0x3ff movgr2fr.d $fa0, $a0
to reduce one instruction. The combination of lu52i.d and movgr2fr.d can always load $2^k$ as a f64 for all integral k in $[0, 1023]$.
But as it's already approved it can be done in a later revision.
Wow that's some serious simplification. I don't think I've seen anything like this recently. Agreed this optimization is better done in a new patch, as it's more of a peephole kind, not deeply related to the generic handling done here.
Quite nice. Thanks for the suggestion. Let’s implement it in later patch. :)