[PATCH] D76096: [clang] allow const structs/unions/arrays to be constant expressions for C

Nick Desaulniers via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 27 14:04:46 PDT 2023


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



More information about the cfe-commits mailing list