Date: Tue, 27 Aug 2024 17:36:10 -0700 From: Mark Millard <marklmi@yahoo.com> To: Brooks Davis <brooks@FreeBSD.org>, dev-commits-ports-main@freebsd.org Subject: RE: git: 58dba5b8212f - main - devel/llvm19: prune build on 32-bit archs Message-ID: <EE856BEC-9EC4-4F46-A546-924FD88552A1@yahoo.com>
index | next in thread | raw e-mail
> Brooks Davis <brooks_at_freebsd.org> wrote on > Date: Tue, 27 Aug 2024 21:19:02 UTC : > > On Tue, Aug 27, 2024 at 07:23:37PM +0000, Brooks Davis wrote: > > The branch main has been updated by brooks: > > > > URL: https://cgit.FreeBSD.org/ports/commit/?id=58dba5b8212fd4dc77e07f58810ae959ae29fc6e > > > > commit 58dba5b8212fd4dc77e07f58810ae959ae29fc6e > > Author: Brooks Davis <brooks@FreeBSD.org> > > AuthorDate: 2024-08-27 19:23:23 +0000 > > Commit: Brooks Davis <brooks@FreeBSD.org> > > CommitDate: 2024-08-27 19:23:23 +0000 > > > > devel/llvm19: prune build on 32-bit archs > > > > Given trends in compiler resource use, it is incresingly implausible to > > consider cross-development from a 32-bit system. As such, stop spending > > time building LLVM bits are are vinishingly unlikely to be used on > > 32-bit systems. > > > > Default to BE_NATIVE (no cross build support) on 32-bit plaforms. > > Disable BE_AMDGPU and BE_WASM as well. BE_AMDGPU consumes enormous > > amounts of memory. BE_WASM is less problematic, but no one has stood up > > to say they need it so turn it off for now. > > > > Completely disable MLIR and POLLY on 32-bit. Just building MLIR fails > > routinly on armv7 and there aren't a lot of direct users (it's used by > > FLANG, but FLANG is 64-bit only). Polly is pretty niche and adds quite > > a bit of build time. > > I'm looking for feedback on this change and plan to merge a version of it > back to older LLVM ports after a suitable period. If you need something > I've disabled in your use case, let me know. Another thing that had some discussion was making the 32-bit ld.lld default for threads behave like --threads=1 when not explicitly set. This mostly avoids memory pressure and, also, the likes of having, say, up to 16 threads active for 4 builders when there are 4 cores if all 4 builders end up running ld.lld in parallel over a time. Is there an intent to also do that? Are you looking for feedback on that idea as well? === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE856BEC-9EC4-4F46-A546-924FD88552A1>