31 ms·
This is controllable by customizing TargetLibraryInfo [1] for your target in LLVM. Note, however, that detecting memcpy is always a valid optimization in C, not
by pcwalton 2y ago
This is controllable by customizing TargetLibraryInfo [1] for your target in LLVM. Note, however, that detecting memcpy is always a valid optimization in C, not just in userspace. The C language standard, not POSIX, requires that a function spelled "memcpy" be available.
As a side note, the optimization pass that detects and replaces memcpy is called LoopIdiomRecognize [2]. It actually detects quite a bit, not just memcpy.
[1]: https://llvm.org/doxygen/TargetLibraryInfo_8cpp_source.html https://llvm.org/doxygen/TargetLibraryInfo_8cpp_source.html
[2]: https://llvm.org/doxygen/LoopIdiomRecognize_8cpp.html https://llvm.org/doxygen/LoopIdiomRecognize_8cpp.html
- MobiusHorizons 2y agoVery Interesting! I guess I would still expect the optimization to use the library implementation of memcpy to be invalid when interacting with memory mapped IO. In this case the issue was the size of writes being issued (byte vs word), but you can easily imagine other issues that would not matter something like memcpy. I would have thought volatile might have signaled this, even if the issue here is not related to values being cached in registers. Does zig have a version of volatile?
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- int_19h 2y agohttps://ziglang.org/documentation/master/#volatile https://ziglang.org/documentation/master/#volatile