tt-metal builds with -mcpu=tt-wh or -mcpu=tt-bh and no -march, and the SFPI toolchain that defines those is fetched as a binary tarball at configure time, so nothing in the tree says whether RVC is enabled. Circumstantially the firmware size budgets are tight and -Os is the default, which suggests it is.
We emit uncompressed only and the loader never disassembles linearly, so it does not care either way today. This only matters if Booth ever needs to interop with firmware objects or read tt-metal's own kernel binaries.
Settling it is a five minute job with hardware present: run readelf -h on a built kernel and check the EF_RISCV_RVC bit, or dump .riscv.attributes.
tt-metal builds with -mcpu=tt-wh or -mcpu=tt-bh and no -march, and the SFPI toolchain that defines those is fetched as a binary tarball at configure time, so nothing in the tree says whether RVC is enabled. Circumstantially the firmware size budgets are tight and -Os is the default, which suggests it is.
We emit uncompressed only and the loader never disassembles linearly, so it does not care either way today. This only matters if Booth ever needs to interop with firmware objects or read tt-metal's own kernel binaries.
Settling it is a five minute job with hardware present: run readelf -h on a built kernel and check the EF_RISCV_RVC bit, or dump .riscv.attributes.