nickdesaulniers added a comment.
In D76096#4537078 <https://reviews.llvm.org/D76096#4537078>, @efriedma wrote:
> The idea is to maintain the parallel infrastructure for structs and arrays,
> but not for other things.
Are you referring specifically to InitListExprs on VarDecls of records
(structs/arrays/unions)?
Consider the following code:
long x [] = {1, 2, 3, 4, 5 + 4};
Even with some of my recent changes, because the fast path parallel
implementation doesn't currently handle BinaryOperator Exprs, we'll visit all
of the ImplicitCastExpr and IntegerLiteral, then eventually figure out that we
can't constant evaluate the final element (for the wrong reasons; i.e.
VisitBinaryOperator not implemented). That's a slow down because then we'll
fall back to EvaluateAsLValue/EvaluateAsRValue which will then succeed.
So we pretty much need a fair amount of parallel implementation for the fast
path to succeed. I'm happy to implement all that, if that's the direction
you're advising?
Or did you mean something else when you said "for structs and arrays?"
> I'm trying to avoid regressions.
I think I've already shown <https://reviews.llvm.org/D76096#4529555> this patch
to be an improvement for the Linux kernel build.
In D76096#4536264 <https://reviews.llvm.org/D76096#4536264>, @nickdesaulniers
wrote:
> Perhaps playing with time to compile programs generated via incbin
> <https://github.com/graphitemaster/incbin> would be a useful test, too?
Sorry, not incbin, xxd <https://unix.stackexchange.com/a/176112> is what I had
in mind.
For another test, if I dump a 7kb image to a c file (image included for
science):
F28472684: danger.jpeg <https://reviews.llvm.org/F28472684>
$ xxd --include ~/Pictures/danger.jpeg > danger.c
$ head -n 3 danger.c
unsigned char _usr_local_google_home_ndesaulniers_Pictures_danger_jpeg[] = {
0xff, 0xd8, 0xff, 0xe0, 0x00, 0x10, 0x4a, 0x46, 0x49, 0x46, 0x00, 0x01,
0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0xff, 0xdb, 0x00, 0x84,
$ wc -l danger.c
637 danger.c
With D76096 <https://reviews.llvm.org/D76096>:
$ hyperfine --runs 3000 'clang -c danger.c -o /dev/null'
Benchmark 1: clang -c danger.c -o /dev/null
Time (mean ± σ): 26.2 ms ± 1.4 ms [User: 15.0 ms, System: 11.1 ms]
Range (min … max): 22.1 ms … 36.6 ms 3000 runs
baseline:
$ hyperfine --runs 3000 'clang -c danger.c -o /dev/null'
Benchmark 1: clang -c danger.c -o /dev/null
Time (mean ± σ): 27.1 ms ± 1.4 ms [User: 15.9 ms, System: 11.2 ms]
Range (min … max): 23.4 ms … 36.1 ms 3000 runs
Is there another way I can prove the absence of regression to you?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D76096/new/
https://reviews.llvm.org/D76096
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
