On Thu, 2026-05-21 at 09:39 +0900, mark.yang via lists.openembedded.org wrote: > From: "mark.yang" <[email protected]> > > Introduce thin-lto-pgo PACKAGECONFIG enabling clang's PGO+ThinLTO bootstrap > for standalone clang builds. > clang-native and llvm-native are separate recipes, so the PGO build runs in > standalone mode. > > Using PGO only for clang optimizes only the frontend, so it is recommended to > also apply PGO optimization to libLLVM (mid-end, backend). > llvm-project assumes PGO optimization is performed when clang and llvm are in > a monorepo. > > Selected the top 10 components using clang as a toolchain in core-image-sato > and compared their do_compile time from buildstat. > Built sequentially to avoid warm cache hits and performed 10 cycles. > Compared the median of compile time. > AMD Ryzen 9 7950x (16 cores, 32 threads) > BB_NUMBER_THREADS = "32" > PARALLEL_MAKE = "-j 32" > TOOLCHAIN = "clang" > PACKAGECONFIG:append:pn-clang-native = " thin-lto-pgo" > > Recipe baseline (s) thin-lto-pgo (s) diff > sqlite3 36.455 35.550 -2.5% > fmt 24.770 21.685 -12.5% > perl 36.470 35.250 -3.3% > libunistring 36.300 30.820 -15.1% > icu 30.930 19.840 -35.9% > librsvg 73.785 74.700 +1.2% > mesa 39.610 28.380 -28.4% > openssl 27.505 20.485 -25.5% > binutils 36.855 33.280 -9.7% > busybox 18.100 16.925 -6.5% > > One-time bootstrap cost: clang-native do_compile 448s -> 1307s
This is definitely interesting work, thanks for sharing it! I'm a bit worried from two perspectives. Firstly, it adds some larger/complex patches which are marked as "Inappropriate" for upstream. These are going to make it hard to update clang versions and generally complicate our maintenance of the clang/llvm recipes. Is there something we could discuss with upstream to remove the need to carry patches? Secondly, I am worried about the compile times. An extra ~900s or 15 minutes is a lot of extra time to add to our builds. I appreciate this isn't turned on by default, but then if it isn't turned on, it isn't going to get tested and this feels like something that could get easily broken. Given those two things, I'm rather reluctant to take patches like this in their current form. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#237707): https://lists.openembedded.org/g/openembedded-core/message/237707 Mute This Topic: https://lists.openembedded.org/mt/119418107/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
