[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