llvm: target mips64r5900el-ps2-elf so EE code links with -flto #20
Loading…
Reference in a new issue
No description provided.
Delete branch "ps2-194-n32-lto"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
PS2-194: lets
opt: -O2 -fltolink EE code with the LLVM toolchain. The EE now compiles formips64r5900el-ps2-elf, the PS2 toolchain's own triple, which implies the R5900 and the n32 ABI.Needs a toolchain built with ps2/llvm#18 (lld n32 bitcode) and ps2/llvm#20 (the PS2 triple). Release order matters: an LLVM toolchain without #20 rejects this triple, so this cannot ship before that toolchain release. Releases don't enforce a compatibility floor between components.
--targetmips64el-unknown-elf→mips64r5900el-ps2-elf-mcpu=r5900 -mabi=n32stay on the command line; they're now redundant but harmless. The earliergnuabin32triple and--plugin-opt=mcpu=r5900are gone.Without
-fltonothing changes: the bench ELF is identical to one built with the old triple, apart from the.commentstring. With-fltothe bench links, and the ELF header saysabi2, 5900, mips3. The LLVM goldens are regenerated, andgo test ./...passes.Not yet run on the console with this triple (the rig service was down). An earlier run with the same lld fix and an equivalent n32 triple matched all 9 checksums.
Follow-up: the llvm-toolchain repo still uses
mips64el-unknown-elfin the clang.cfgand in the compiler-rt, libc++ and emutls builds.🤖 Generated with Claude Code
llvm: build EE code that links with -fltoto llvm: target mips64r5900el-ps2-elf so EE code links with -fltoConsole rig with this branch and a dev toolchain containing ps2/llvm#18 and #20: the bench built with
opt: -O2 -fltoand withopt: -O2passes, and all 9 checksums match. Runs 20261015T220417-0201 (LTO) and 20261015T220425-0202 (no LTO).