[PATCH] D106426: [FuncSpec] Support specialising recursive functions
Sjoerd Meijer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 27 03:15:31 PDT 2021
SjoerdMeijer added a comment.
> If we run bin/opt -function-specialization -func-specialization-max-iters=10 -S %s, we could find that recursiveFunc would get specialized 18 times.
This is not not true. It will get specialised 10 times.
> Then I run bin/opt -function-specialization -func-specialization-max-iters=10 -inline -instcombine -simplifycfg -S %s, I got:
> <SNIP>
> hmmmm, I guess it must not be your expected code, right?
Hmmm, sorry, this is exactly what I expect. Look at the generated code:
_main: ; @main
stp x20, x19, [sp, #-32]! ; 16-byte Folded Spill
stp x29, x30, [sp, #16] ; 16-byte Folded Spill
adrp x19, _funcspec.arg.17 at PAGE
add x19, x19, _funcspec.arg.17 at PAGEOFF
LBB1_1:
mov w0, #1
bl _print_val
LBB1_2:
mov w0, #2
bl _print_val
LBB1_3:
mov w0, #3
bl _print_val
LBB1_4:
mov w0, #4
bl _print_val
LBB1_5:
mov w0, #5
bl _print_val
LBB1_6:
mov w0, #6
bl _print_val
LBB1_7:
mov w0, #7
bl _print_val
LBB1_8:
mov w0, #8
bl _print_val
LBB1_9:
mov w0, #9
bl _print_val
mov x0, x19
bl _recursiveFunc
bl _exit_cond
tbnz w0, #0, LBB1_9
bl _exit_cond
tbnz w0, #0, LBB1_9
bl _exit_cond
tbnz w0, #0, LBB1_9
bl _exit_cond
tbnz w0, #0, LBB1_9
bl _exit_cond
tbnz w0, #0, LBB1_8
bl _exit_cond
tbnz w0, #0, LBB1_8
bl _exit_cond
tbnz w0, #0, LBB1_8
bl _exit_cond
tbnz w0, #0, LBB1_8
bl _exit_cond
tbnz w0, #0, LBB1_8
bl _exit_cond
tbnz w0, #0, LBB1_7
bl _exit_cond
tbnz w0, #0, LBB1_7
bl _exit_cond
tbnz w0, #0, LBB1_7
bl _exit_cond
tbnz w0, #0, LBB1_7
bl _exit_cond
<SNIP: a few more>
That seem fairly optimal to me, so don't know why we wouldn't be doing this, or what we need to differently.
> I think all of them would be affected. The impact on code-size is obvious. For the compile-time, it would take a long time to compile if we set the argument func-specialization-max-iters to 2000.
I am sorry, but this is an unreasonable number. There is no point in discussing such a big number, because the default will never be even close to that, and if you do want to set it to very high, then that's opt-in and your responsibility.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106426/new/
https://reviews.llvm.org/D106426
More information about the llvm-commits
mailing list