jrtc27 added a comment. In D71387#2762115 <https://reviews.llvm.org/D71387#2762115>, @khchen wrote:
> In D71387#1820995 <https://reviews.llvm.org/D71387#1820995>, @efriedma wrote: > >> Okay. Please let me know if you want me to review anything. > > Hi all, > We had encoded the target-abi into module now, but I feel it does not make > sense to > support overwrite ABI option and datalayout in TargetMahcine/IR by target-abi > module flag in IR. > > So I think maybe passing the target-abi option by clang driver can make > anything more simple, the only one limitation is users need to specific > `-mabi` in below cases at the last command. > > clang -target riscv64-unknown-elf a.c -flto -march=rv64gc -mabi=lp64f -o a.o > clang -target riscv64-unknown-elf b.c -flto -march=rv64gc -mabi=lp64f -o b.o > clang -target riscv64-unknown-elf a.o b.o -flto -march=rv64gc -o foo We should treat a missing `-mabi=` as an implicit `-mabi=whatever-the-default-is` for consistency with non-LTO. So yes, if the default ABI differs from what you've compiled the .o's with, you should have to provide it. This is needed already _anyway_ for multilib toolchains to determine the right library search path, though there are cases currently when you can get away without providing it, at least with Clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71387/new/ https://reviews.llvm.org/D71387 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
