]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: Speed up compilation of large char array initializers when not using #embed
authorJakub Jelinek <jakub@redhat.com>
Tue, 21 Jan 2025 08:15:53 +0000 (09:15 +0100)
committerJakub Jelinek <jakub@gcc.gnu.org>
Tue, 21 Jan 2025 08:15:53 +0000 (09:15 +0100)
commitf31d49d65412d03d2cf91dd3b8b7281815c6d03b
treec15f85103f8c7dba23b48d6ac75a6940bd6efae9
parent2a6816883107ee4a4aabb43763ce079512f3f0f8
c++: Speed up compilation of large char array initializers when not using #embed

The following patch (again, on top of the #embed patchset
attempts to optimize compilation of large {{{,un}signed ,}char,std::byte}
array initializers when not using #embed in the source.

Unlike the C patch which is done during the parsing of initializers this
is done when lexing tokens into an array, because C++ lexes all tokens
upfront and so by the time we parse the initializers we already have 16
bytes per token allocated (i.e. 32 extra compile time memory bytes per
one byte in the array).

The drawback is again that it can result in worse locations for diagnostics
(-Wnarrowing, -Wconversion) when initializing signed char arrays with values
128..255.  Not really sure what to do about this though unlike the C case,
the locations would need to be preserved through reshape_init* and perhaps
till template instantiation.
For #embed, there is just a single location_t (could be range of the
directive), for diagnostics perhaps we could extend it to say byte xyz of
the file embedded here or something like that, but the optimization done by
this patch, either we'd need to bump the minimum limit at which to try it,
or say temporarily allocate a location_t array for each byte and then clear
it when we no longer need it or something.
I've been using the same testcases as for C, with #embed of 100'000'000
bytes:
time ./cc1plus -quiet -O2 -o test4a.s2 test4a.c

real    0m0.972s
user    0m0.578s
sys     0m0.195s
with xxd -i alternative of the same data without this patch it consumed
around 13.2GB of RAM and
time ./cc1plus -quiet -O2 -o test4b.s4 test4b.c

real    3m47.968s
user    3m41.907s
sys     0m5.015s
and the same with this patch it consumed around 3.7GB of RAM and
time ./cc1plus -quiet -O2 -o test4b.s3 test4b.c

real    0m24.772s
user    0m23.118s
sys     0m1.495s

2025-01-21  Jakub Jelinek  <jakub@redhat.com>

* parser.cc (cp_lexer_new_main): Attempt to optimize large sequences
of CPP_NUMBER with int type and values 0-255 separated by CPP_COMMA
into CPP_EMBED with RAW_DATA_CST u.value.
gcc/cp/parser.cc