[libc-commits] [clang] [libc] [llvm] [libc] Implement (v|f)printf on the GPU (PR #96369)

[Joseph Huber via libc-commits]

jhuber6 wrote:

> Do we want some sort of optimization for constant printf? 99% of the time, we could parse the string at compile-time. (This sort of optimization is common for embedded targets.)

I was going to make a follow-up patch that simply skipped sending back the size if there were no arguments to parse. If we enable these builtins as available on the GPU (Which I may very soon) we will also get `printf -> puts` optimizations. There's no passes that optimize things like `printf('%d", 10)` to `puts("10")` as far as I know.

> If the format string isn't constant, is parsing the string on the GPU really slower than asking the host for the size? printf format strings aren't that complicated, especially if you aren't actually doing the formatting.

Well, this approach basically trades speed for resource usage. I had an old implementation that did the parsing on the GPU side, (https://reviews.llvm.org/D158774), and that had an unfortunate amount of registers used when the arguments are truly just an array in this sense. Plus, since I wrote that there's been a lot more added to the format parsing, since I think future C releases are supposed to support 128 bit integers or something.

I think my old version used something like 54 SGPRs and 40 VGPRs while this version is
```
printf.c:4:0: Function Name: foo                                                                                                                                      
printf.c:4:0:     SGPRs: 36
printf.c:4:0:     VGPRs: 19
```
 
> Does this support `%n`?

No, I specifically disabled it in the `printf` config. The fact that it writes back a pointer made it too annoying to implement, and I think in general people consider `%n` a security issue so it's probably not a huge loss.

https://github.com/llvm/llvm-project/pull/96369