3 ms·

A less-evil example is that most compilers can recognize when you wrote a memcpy() and replace it with an actual memcpy() call, which is usually very carefully

by remram 4y ago

A less-evil example is that most compilers can recognize when you wrote a memcpy() and replace it with an actual memcpy() call, which is usually very carefully optimized for your specific processor. This can cause fun issues like your version of memcpy() (e.g. embedded libc) being replaced by the compiler with a call to itself: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

tialaramex 4y ago
The ability to figure out what you're doing and then just do that well, rather than attempting to optimise the code you wrote is called Idiom Recognition and has been around for a very long time, like, 1970s or maybe before. A relatively modern example was people writing code to count set bits in a value, because older languages don't provide an intrinsic to do that and it's often useful, these days your CPU probably has a CPU instruction specifically for that, it's called "popcount" (sometimes spelled popcnt) and so it's valuable to recognise what's going on in the say six lines of C++ in your program and emit a single POPCOUNT instruction instead. If your fancy method to count bits isn't recognised your program goes slower. The memcpy case is special because C is weird in actually trying to define this as a function, copying memory is so commonly necessary that compilers need to have a pre-baked implementation for the rest of what they do anyway, it's not a surprise that idiom recognition results in your custom memcpy being turned into the built-in memcpy, although in the case you linked that's indeed a bug.
kazinator 4y ago
That's due to the run-time and compiler being different projects. In Lisps it's not unusual to see (defun car (x) (car x)). Arguably, memcpy belongs in libgcc and not the C library. Glibc should not have to do anything in regard to memcpy, other than include the right compiler header in its stdlib.h.

by remram 4y ago

tialaramex 4y ago

The ability to figure out what you're doing and then just do that well, rather than attempting to optimise the code you wrote is called Idiom Recognition and has been around for a very long time, like, 1970s or maybe before. A relatively modern example was people writing code to count set bits in a value, because older languages don't provide an intrinsic to do that and it's often useful, these days your CPU probably has a CPU instruction specifically for that, it's called "popcount" (sometimes spelled popcnt) and so it's valuable to recognise what's going on in the say six lines of C++ in your program and emit a single POPCOUNT instruction instead. If your fancy method to count bits isn't recognised your program goes slower. The memcpy case is special because C is weird in actually trying to define this as a function, copying memory is so commonly necessary that compilers need to have a pre-baked implementation for the rest of what they do anyway, it's not a surprise that idiom recognition results in your custom memcpy being turned into the built-in memcpy, although in the case you linked that's indeed a bug.

kazinator 4y ago

That's due to the run-time and compiler being different projects. In Lisps it's not unusual to see (defun car (x) (car x)). Arguably, memcpy belongs in libgcc and not the C library. Glibc should not have to do anything in regard to memcpy, other than include the right compiler header in its stdlib.h.