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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
