[PATCH] D71387: pass -mabi to LTO linker only in RISC-V targets, enable RISC-V LTO

Kuan Hsu Chen (Zakk) via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Dec 17 22:12:26 PST 2019


khchen added a comment.

In D71387#1788472 <https://reviews.llvm.org/D71387#1788472>, @efriedma wrote:

> > Unfortunately on RISCV, the ABI info is only derived from -mabi option and the target triple does not encode ABI info (same to gcc).
>
> How does gcc decide the default ABI for a target?  Do you explicitly specify it at configure time?


Yes, default March/ABI are decided in configure time, and there is also default March/ABI there.

>> example 1:
>>  What's expected behavior? user specifics -mabi=lp64f so the result object ABI is lp64f?
> 
> I think the expected behavior is a fatal error.  There isn't any reason to let people shoot themselves in the foot like this.  (module flags have builtin support for producing such an error.)
> 
>> example 2:
>>  What's expected behavior? The result object is -mabi=lp64f because they have same ABI in module metadata?
> 
> Yes.
> 
>> there is no problem (I think) when overwriting the original ABI. (so the mixing ABI is not a problem)
> 
> clang emits different IR for hardfloat vs. softfloat targets; if you try to overwrite the ABI of a bitcode file, we'll generate wrong code.

Do you mean different function attributes for different ABI targets?
I see there are `arm_aapcs_vfpcc` annotation and `use-soft-float=false` in attributes when giving the `-mfloat-abi=hard` option.
But in RISCV clang emits the same IR for different ABI (-mabi), so maybe it is no problem in RISCV?  (-mfloat-abi is unused in riscv clang driver)


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