armv7 (and other 32-bit platforms): does your armv7 environment operation actually depend on a devel/llvm* having provided BE_AMDGPU? BE_WASM? . . .

[Note: The "why?" behind the just below and the questions associated
is covered alter in the material.]

There is a proposal in review [ https://reviews.freebsd.org/D46239 ]
to have 32-bit platforms (armv7, armv6, i386, and (32-bit) powerpc
have as defaults for at least devel/llvm19 :

---Begin OPTIONS List---
===> The following configuration options are available for llvm19-19.1.0.r2:
BE_AMDGPU=off: AMD GPU backend (required by mesa)
BE_WASM=off: WebAssembly backend (required by firefox via wasi)
CLANG=on: Build clang
DOCS=on: Build and/or install documentation
EXTRAS=on: Extra clang tools
LIT=on: Install lit and FileCheck test tools
LLD=on: Install lld, the LLVM linker
LLDB=on: Install lldb, the LLVM debugger
PYCLANG=on: Install python bindings to libclang
STATIC_LIBS=on: Install static libraries (does not effect sanitizers)
====> Options available for the single BACKENDS: you have to select exactly one of them
BE_FREEBSD=off: Backends for FreeBSD architectures
BE_NATIVE=on: Backend(s) for this architecture (ARM)
BE_STANDARD=off: All non-experimental backends
===> Use 'make config' to modify these settings

Note the lack of: MLIR and POLLY. So those 2 being
not even possible without editing the Makefile if the
proposed changes stay as they are.

Such defaults mean that the FreeBSD package distributions
for, say, armv7, would not include things dependent on
the missing options --or on the "off" options. For example
. . .

Relative to BE_AMDGPU via mesa* examples:

# pkg rquery -rFreeBSD -g %ro 'mesa*' | sort -u
audio/plasma5-kpipewire
audio/plasma6-kpipewire
benchmarks/glmark2
benchmarks/vkmark
comms/cubicsdr
databases/compass
devel/electron29
devel/sdl20
devel/sdl3
emulators/libretro-reicast
emulators/qemu
emulators/qemu-devel
emulators/qemu8
emulators/reicast
games/retroarch
graphics/cogl
graphics/kmscube
graphics/libosmesa
graphics/mesa-devel
graphics/mesa-dri
graphics/piglit
graphics/waffle
multimedia/arcan
multimedia/kodi
multimedia/mpv
multimedia/wf-recorder
net-im/tg_owt
net/neatvnc
net/tigervnc-server
net/waypipe
net/wayvnc
net/wlvncc
sysutils/inxi
sysutils/plasma5-kinfocenter
sysutils/plasma6-kinfocenter
www/chromium
www/iridium
www/qt6-webengine
www/ungoogled-chromium
x11-drivers/xf86-video-amdgpu
x11-drivers/xf86-video-vmware
x11-servers/xarcan
x11-servers/xorg-server
x11-servers/xwayland
x11-toolkits/aquamarine
x11-toolkits/scenefx
x11-toolkits/wlroots
x11-toolkits/wlroots-hyprland
x11-toolkits/wlroots015
x11-toolkits/wlroots016
x11-toolkits/wlroots017
x11-wm/compiz
x11-wm/cosmic-comp
x11-wm/hyprland
x11-wm/magpie
x11-wm/mutter
x11-wm/niri
x11-wm/plasma5-kwin
x11-wm/plasma6-kwin
x11/gnome-shell
x11/hyprlock
x11/virglrenderer
x11/xdg-desktop-portal-hyprland
x11/xdg-desktop-portal-wlr
x11/xorg

Relative to BE_WASM there seem to be at
least :

www/firefox
www/firefox-esr
www/librewolf
www/tor-browser
www/waterfox
www/thunderbird

Relative to devel/llvm* use: Do you cross build
on a 32-bit platform to produce BE_FREEBSD or
BE_STANDARD targeted builds via devel/llvm* use
that is not to BE_NATIVE targets?

Overall:
Do you use any of these (BE_AMDGPU, BE_WASM,
cross-builds) on a 32-bit system? If yes, which
and on what platform? How common is such usage
overall?


Why? . . .

Things have grown such that devel/llvm19's existing OPTIONS_DEFAULT
related assignments lead to OOM kills:

QUOTE of a report (with a correction in []'s)
llvm ports with default configuration causes OOM on a 4-core armv7
with [2]G RAM/16G swap, on a 4-core aarch64 with 4G RAM/16G swap
and on a 16-core aarch64 with 16G RAM/16G swap.
END QUOTE

I presume this is with no other builder active but with it allowed
to use all the cores in each case. I'm unsure if other possibly
notable competition for RAM+SWAP was involved, say, for example,
via tmpfs use.

This is leading to the review for potentially changing the
OPTIONS_DEFAULT related assignments in devel/llvm19/Makefile
for 32-bit platforms to better fit native armv7 hardware and
other 32-bit hardware.

I've done testing of doing armv7 builds on a RPi4B configured to
use about 2 GiBytes of RAM and on a native Cortex-A7 armv7 in a
orange-Pi+ 2ed. The changes do look to avoid the OOM conditions
for local poudiere bulk based builds. BE_AMDGPU was the biggest
RAM+SWAP usage option for building devel/llvmn19. Next down the
list was BE_FREEBSD. (But I did not test BE_STANDARD.) Finally,
BE_WASM made little difference in the RAM+SWAP usage for building
devel/llvm19 with the option.

Note: Just because BE_WASM did not contribute much to RAM+SWAP
use for building devel/llvm19 does not necessarily mean that,
say, building www/firefox-esr would fit well. Such could lead
to BE_WASM not being important to have enabled.

===
Mark Millard
marklmi at yahoo.com