[PATCH] D71387: pass -mabi to LTO linker only in RISC-V targets, enable RISC-V LTO
Zakk Chen via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sun May 16 19:43:49 PDT 2021
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
More information about the cfe-commits
mailing list