khchen added a comment. In D71387#2762120 <https://reviews.llvm.org/D71387#2762120>, @jrtc27 wrote:
> 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. Hi @jrtc27, do you mean in clang, we need encode an explicitly -target-abi string (compute by RISCVABI::computeTargetABI) rather than an empty string in IR module? 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
