I'm not really sure if that's possible... there's also the issue of loss of precision with floats and int64. A float64 has only 52 bits of mantissa and large int64 results will be imprecise and…
and why can't we use the intrinsic? is it removed in newer versions?
Yes another way is to use the double**int -> double
llvm intrinsic (llvm does not provide int**int -> int
intrinsic..).…
I think it should be faster, both __builtin_memmove
and __builtin_memcpy
are translated into llvm intrinsics, and llvm intrinsics for memmove allows overlap while memcpy does not allow. So…
Does it play nice with constant propagation/folding? A common situation is shifting bits by multiplying by a power of 2, and this absolutely has to be folded. The code in the legacy compiler uses…
I tentatively move all the ir runtime library related code to nac3core/codegem/nac3irrt, hopefully this will be better
So is it ok to use some patch like the below so that we can call the unwrapped clang without calling clang-13
to output wasm32 llvm bitcode here?
diff --git a/flake.nix…
Removed in the new commits. Indeed this fast path only optimize the a small amount of common cases (even not things like a[:], b[:] = c[:], d[:]
due to the assignment unpacking).
Ah thanks I see, then I think I also need to change the code to modify the list length in the rust side.
In c I seem to also failed to find a way to call stacksave
and stackrestore
manually... But here I think this should be fine since this temp array will be freed when exiting this slice assignment…