khchen added a comment. In D71387#1786518 <https://reviews.llvm.org/D71387#1786518>, @efriedma wrote:
> My primary concern with this is that I'm not sure you should be passing this > information separately, as opposed to encoding it into the bitcode. > > On ARM, the ABI for a file is generally derived from the target triple. For > example, "arm-eabi" is soft-float, "arm-eabihf" is hard-float. This makes > the intended target clear, provides some protection against accidentally > using LTO with files compiled for different ABIs, and matches up well with > our existing configuration flags to set a default target for a compiler. > For other ABI-ish sorts of questions, LLVM IR also supports module flags, > which can specify various parameters that apply to an entire object file. > See, for example, > http://llvm.org/docs/LangRef.html#c-type-width-module-flags-metadata . This > has some of the same benefits: it clearly applies to the whole file, and it > detects mixing targets with LTO. @efriedma Thank you for your information. Unfortunately on RISCV, the ABI info is only derived from `-mabi` option and the target triple does not encode ABI info (same to gcc). In addition, the resulting object file only uses one ABI. If we choose the module flags metadata solution, there are some problems about which ABI should be chosen when linking different ABIs. example 1: clang -target riscv64-unknown-elf a.c -flto -march=rv64imf `-mabi=lp64f` -o a.o clang -target riscv64-unknown-elf b.c -flto -march=rv64i `-mabi=lp64` -o b.o clang -target riscv64-unknown-elf -march=rv64imf -mabi=lp64f a.o b.o -flto -o foo What's expected behavior? user specifics `-mabi=lp64f` so the result object ABI is `lp64f`? example 2: clang -target riscv64-unknown-elf a.c -flto -march=rv64imf -mabi=lp64f -o a.o clang -target riscv64-unknown-elf b.c -flto -march=rv64i -mabi=lp64f -o b.o clang -target riscv64-unknown-elf a.o b.o -flto -o foo What's expected behavior? The result object is `-mabi=lp64f` because they have same ABI in module metadata? example 3: clang -target riscv64-unknown-elf a.c -flto -march=rv64imf `-mabi=lp64f` -o a.o clang -target riscv64-unknown-elf b.c -flto -march=rv64imf `-mabi=lp64` -o b.o clang -target riscv64-unknown-elf a.o b.o -flto -o foo What's expected behavior? Use the default `march` and `mabi`? RISCV clang driver has default `march` and `mabi`, so I think maybe it's a easier and clear way to overwrite ABI via option only for RISCV target, and there is no problem (I think) when overwriting the original ABI. (so the mixing ABI is not a problem) BUT in https://reviews.llvm.org/D67385#1680959 @tejohnson taught me that "LLVM are going more and more toward a model where info is communicated via the IR from the compile step", So I'm wondering if passing the ABI via option to LTO ONLY for specific target, is it still a bad ideal? Thanks. 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
