[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