Some packages depend on MLIR in LLVM, so MLIR should be enabled by default.
Created attachment 240548 [details] patch
I think this will make users of 32-bit platforms even sadder. Should we enable it by default on 64-bit systems like we did implicitly when FLANG was enabled?
(In reply to Brooks Davis from comment #2) > I think this will make users of 32-bit platforms even sadder. But why is this? Compiler doesn't fit in 3GB?
It's been a while since I had reports due to not enabling MLIR on 32-bit systems unless people enabled it explicitly, but IIRC people were hitting OOM conditions, possibly due to not configuring enough swap.
(In reply to Brooks Davis from comment #4) One can hit OOM when a single process grows over 3GB on i386. It's possible that MLIR can trigger this, but it looks unlikely. Maybe a good strategy would be to enable MLIR in general, and then later to disable it on 32-bit platforms in case of either fallout or valid user complaints? I disabled a few ports on 32-bit architectures due to fallout from OOM conditions.
That's probably worth trying.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d952cecfb0e509a9a80bbe05d985cc155c0e4672 commit d952cecfb0e509a9a80bbe05d985cc155c0e4672 Author: Brooks Davis <brooks@FreeBSD.org> AuthorDate: 2023-03-06 23:21:53 +0000 Commit: Brooks Davis <brooks@FreeBSD.org> CommitDate: 2023-03-06 23:27:24 +0000 devel/llvm16: enable MLIR by default, fix aarch64 Some ports require on MLIR so reenable it by default. This turns it on for all platforms where it was previously disabled for 32-bit platforms and pulled in indirectly by FLANG. If this proves to cause too many user issues we'll disable it for 32-bit again.[0] Fix a missed 16.0.0->16 change in backend include directories which broke aarch64 with BE_NATIVE. Also enable the ARM (32-bit) backend on aarch64 as it's plausiably useful.[1] PR: 269927 [0] Reported by: yuri [0], Mark Millard <marklmi@yahoo.com> [1] devel/llvm16/Makefile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
Could you please also do the same for devel/llvm-devel?
(In reply to Yuri Victorovich from comment #3) FYI: on aarch64 (such as the FreeBSD package builder for armv7 ports), the process size limit for armv7 is more like 2 GiBytes, not 3 GiBytes. The Orange Pi Plus 2ed that I have access to has a larger process maximum size than the aarch64-as-armv7 systems do --but less than 3 GiBytes (closer to 2 GiBytes). (I've no clue if the 2 GiByte or so aarch64-as-armv7 limit is just a FreeBSD choice to simplify things or not.) There are armv7 ports that aarch64-as-armv7 can not build but some armv7 systems can. The one I investigated once I also could not build on the Orange Pi Plus 2ed but someone else had a armv7 system that managed to do the build in question. I do not know what the process size limit was for their context. Their system lead to not classifying the port as broken for armv7, despite how many systems would be unable to build the port in question, including the package builder for armv7. (So far as I know, the ports infrastructure does not have a classification for "not broken but do not bother to waste time/power on the build server(s)".)
MLIR was never disabled on llvm-devel so I think this is fully resolved.