rrent@freebsd.org>, FreeBSD-STABLE Mailing List , brooks@freebsd.org Subject: Re: performance regressions in 15.0 Message-ID: References: <18FB2858-5CBB-4B7A-8089-224A58C6A160@yahoo.com> <20251208035105.2313075d@rimwks.local> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251208035105.2313075d@rimwks.local> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; TAGGED_RCPT(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[kib]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org,freebsd-current@freebsd.org]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,bsdimp.com,yahoo.com,freebsd.org]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4dPlXd6Vvyz3QPc On Mon, Dec 08, 2025 at 03:51:05AM +0200, Rozhuk Ivan wrote: > On Mon, 8 Dec 2025 02:15:33 +0200 > Konstantin Belousov wrote: > > > Next, the change of llvm components to dynamically link with the llvm > > libs is how upstream does it. Not to mention, that this way to use > > clang+lld saves both disk space (not very important) and memory (much > > more important). > > It waste time and energy = money waster, "multiply CO2 production". > And there is nothing good to user to pay this price. > > > I have: > > # pkg version -vI | grep llvm > libclc-llvm15-15.0.7 = up-to-date with index > llvm15-15.0.7_10 = up-to-date with index > llvm17-17.0.6_8 = up-to-date with index > llvm18-18.1.8_2 = up-to-date with index > llvm19-19.1.7_1 = up-to-date with index > > there is no any crappy libprivateclang.so/libprivatellvm.so shared libs: > > # ldd /usr/local/llvm19/bin/clang-19 > /usr/local/llvm19/bin/clang-19: > libthr.so.3 => /lib/libthr.so.3 (0x801063000) > libclang-cpp.so.19.1 => /usr/local/llvm19/bin/../lib/libclang-cpp.so.19.1 (0x801200000) > libLLVM.so.19.1 => /usr/local/llvm19/bin/../lib/libLLVM.so.19.1 (0x805c00000) Did you noted this line? > libc++.so.1 => /lib/libc++.so.1 (0x801092000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80119b000) > libm.so.5 => /lib/libm.so.5 (0x8011bd000) > libc.so.7 => /lib/libc.so.7 (0x80d663000) > librt.so.1 => /lib/librt.so.1 (0x805bcb000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x805bd4000) > libz.so.6 => /lib/libz.so.6 (0x805bda000) > libzstd.so.1 => /usr/local/lib/libzstd.so.1 (0x80d963000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80da38000) > libelf.so.2 => /lib/libelf.so.2 (0x80da59000) > [vdso] (0x7ffffffff000) > > But > # ls /usr/bin/cc > -r-xr-xr-x 6 root wheel 82M Oct 19 18:10:39 2025 /usr/bin/cc* > # ls /usr/local/llvm19/bin/clang-19 > -rwxr-xr-x 2 root wheel 125K Aug 18 06:43:31 2025 /usr/local/llvm19/bin/clang-19* > So it dynamic linked.... > .... > And we found in port: > CMAKE_ARGS= -DLLVM_BUILD_LLVM_DYLIB=ON > CMAKE_ARGS+= -DLLVM_LINK_LLVM_DYLIB=ON > (exist from first llvm6 372b8a151352984140f74c342a62eae2236b2c2c and copy-pasted to all next llvm~s by brooks@FreeBSD.org) > > According to: https://llvm.org/docs/CMake.html > ============================================================================================= > BUILD_SHARED_LIBS is only recommended for use by LLVM developers. > If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option. > ============================================================================================= > > So upstream DOES NOT RECOMMEND to build shared libs to users!!! I am curious about the motivation. JFYI, shared llvm libs are required for lot of things. The incomplete list of examples that I am aware of are dri drivers and ispc Intel compiler. > > Why FBSD use shared libs for LLVM in ports and now in base!??? > > @brooks - why do you do that? > > > > The implied load on rtld is something that could be handled: there is > > definitely no need to have such huge surface of exported symbols on > > both libllvm and esp. libclang. Perhaps by default the internal > > libraries can use protected symbols, normally C++ do not rely on > > interposing. But such 'fixes' must occur at upstream. > > > > So far all the clang toolchain changes were aligning it with what the > > llvm project does. > > > > No, upstream does not recommend to use shared libs to llvm users.