2 ms·
Whoa, this is quite the rabbit hole. This commit [1] and it’s partner [2] suggest that at least around 2016, there is some really special case “yeah, but we rea
by boulos 7y ago
Whoa, this is quite the rabbit hole. This commit [1] and it’s partner [2] suggest that at least around 2016, there is some really special case “yeah, but we really want printf”. I couldn’t find the CUDA runtime implementation on my phone, but now I’m curious what the PTX for a device function that calls printf looks like (like perhaps it does a bunch of stuff to emit a call to the host’s C printf, except it has/had to do so in a sort of strange way of building up buffers of things to print / exiting and coming back afterwards).
[1] https://reviews.llvm.org/D16484 https://reviews.llvm.org/D16484
[2] https://reviews.llvm.org/D16559 https://reviews.llvm.org/D16559
- dahart 7y agoI’m going to look it up Monday, pretty sure there is something surprising in the printf impl, and IIRC there’s like no type safety at all. I vaguely remember writing buggy code that printed out data that I didn’t pass to printf.
- boulos 7y agoThat’s common though for variadic functions, particularly printf! Many printf implementations will blindly do a va_arg (popping the stack pointer by 4 or 8 bytes) if the format string says so. If your call to printf looks like: printf(“%d %d %d %d”, x, y); then you’re going to “read” two more ints from the stack at the call site. clang (and later gcc, I think) thus have a semantic analysis pass that understands/parses printf-style formatting strings so it can tell “hey, you didn’t pass enough arguments” or just as frequently “you passed too few”.