Repository navigation
build: wasm-to-js-tq-csa.cc takes ages to compile #52068
Description
Commit 78be0d0, linux x86_64, g++ 12.3.0. I observe that the generated file wasm-to-js-tq-csa.cc takes > 20 minutes to compile on an otherwise fast system.
It's a fairly big file (391k, just under 7kLoC) but not that big (template heavy, however.) Other, much bigger torque files compile in seconds flat.
Possibly hits a pathological case in gcc. I wasn't really able to draw any conclusions from looking at perf top except that it was working hard. Perhaps tweaking compiler flags helps.
bnoordh+ 119949 98.4 7.0 1229736 1142472 pts/1 R+ 11:04 14:19 /usr/lib/gcc/x86_64-linux-gnu/12/cc1plus -quiet -I ../deps/v8 -I ../deps/v8/include -I /home/bnoordhuis/src/node/out/Release/obj/gen -I /home/bnoordhuis/src/node/out/Release/obj/gen/generate-bytecode-output-root -I ../deps/icu-small/source/i18n -I ../deps/icu-small/source/common -imultiarch x86_64-linux-gnu -MMD /home/bnoordhuis/src/node/out/Release/obj.target/v8_initializers/gen/torque-generated/src/builtins/wasm-to-js-tq-csa.d -MF /home/bnoordhuis/src/node/out/Release/.deps//home/bnoordhuis/src/node/out/Release/obj.target/v8_initializers/gen/torque-generated/src/builtins/wasm-to-js-tq-csa.o.d.raw -MQ /home/bnoordhuis/src/node/out/Release/obj.target/v8_initializers/gen/torque-generated/src/builtins/wasm-to-js-tq-csa.o -D_GNU_SOURCE -D_REENTRANT -D _GLIBCXX_USE_CXX11_ABI=1 -D NODE_OPENSSL_CONF_NAME=nodejs_conf -D NODE_OPENSSL_HAS_QUIC -D ICU_NO_USER_DATA_OVERRIDE -D V8_GYP_BUILD -D V8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -D __STDC_FORMAT_MACROS -D OPENSSL_NO_PINSHARED -D OPENSSL_THREADS -D V8_TARGET_ARCH_X64 -D V8_HAVE_TARGET_OS -D V8_TARGET_OS_LINUX -D V8_EMBEDDER_STRING="-node.13" -D ENABLE_DISASSEMBLER -D V8_PROMISE_INTERNAL_FIELD_COUNT=1 -D V8_ENABLE_PRIVATE_MAPPING_FORK_OPTIMIZATION -D V8_SHORT_BUILTIN_CALLS -D OBJECT_PRINT -D V8_INTL_SUPPORT -D V8_ATOMIC_OBJECT_FIELD_WRITES -D V8_ENABLE_LAZY_SOURCE_POSITIONS -D V8_USE_SIPHASH -D V8_SHARED_RO_HEAP -D V8_WIN64_UNWINDING_INFO -D V8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -D V8_USE_ZLIB -D V8_ENABLE_MAGLEV -D V8_ENABLE_TURBOFAN -D V8_ENABLE_WEBASSEMBLY -D V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS -D V8_ALLOCATION_FOLDING -D V8_ALLOCATION_SITE_TRACKING -D V8_ADVANCED_BIGINT_ALGORITHMS -D UCONFIG_NO_SERVICE=1 -D U_ENABLE_DYLOAD=0 -D U_STATIC_IMPLEMENTATION=1 -D U_HAVE_STD_STRING=1 -D UCONFIG_NO_BREAK_ITERATION=0 /home/bnoordhuis/src/node/out/Release/obj/gen/torque-generated/src/builtins/wasm-to-js-tq-csa.cc -quiet -dumpdir /home/bnoordhuis/src/node/out/Release/obj.target/v8_initializers/gen/torque-generated/src/builtins/ -dumpbase wasm-to-js-tq-csa.cc -dumpbase-ext .cc -m64 -mtune=generic -march=x86-64 -O3 -O3 -Wno-unused-parameter -Wno-return-type -Wno-invalid-offsetof -std=gnu++17 -flax-vector-conversions -fno-strict-aliasing -fno-omit-frame-pointer -fdata-sections -ffunction-sections -fno-rtti -fno-exceptions -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o /tmp/ccsXRDpk.s
Activity
targos commentedon Mar 13, 2024
The issue seems even worse with C++20, see #45427
Seems fixed in GCC 13.
bnoordhuis commentedon Mar 13, 2024
I'm okay with closing this but maybe it's an idea to kick the optimization level down a notch for that file for now? It makes rebuilds rather painful.
targos commentedon Mar 13, 2024
Do you know how to do it with gyp?
bnoordhuis commentedon Mar 14, 2024
You put the file in its own target and give it custom cflags/ldflags/etc.
That said, it's extracted from BUILD.gn with that tools/v8_gypfiles/GN-scraper.py script, isn't it? That complicates things a bit.
targos commentedon Mar 14, 2024
I guess we can manually remove it from the existing target's sources by adding a
'sources!'array.build: speed up compilation of some V8 files
targos commentedon Mar 14, 2024
#52083
build: speed up compilation of some V8 files