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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
