khchen added a comment. @lenary (Sorry for the very late reply...)
In D71124#1829998 <https://reviews.llvm.org/D71124#1829998>, @lenary wrote: > In D71124#1792216 <https://reviews.llvm.org/D71124#1792216>, @khchen wrote: > > > The problem is how `-mcpu` interact with explicitly specified `-march` (or > > target features). > > > > 1. in GCC, -mcpu is only used to chose the pipeline model, > > > I think you mean "in GCC, `-mtune` is only used to choose the pipeline model" > (`-mcpu` is not documented in the RISC-V specific GCC options documentation > <https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html>). Yes, It's my mistake, I mean `-mtune`. > Clang should attempt to maintain compatibility with GCC flags, but if they > only implement `-mtune`, then we have a little more freedom to do something > ergonomic with `-mcpu`. > > I'll note that clang already has a large TODO around implementing `-mtune` in > general, though the AArch64 backend seems to support it for some option > choices. > >> >> >> 2. I also read this >> <https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu> >> article talking about the X86 and ARM to handle those options. >> - -march=X: Tells the compiler that X is the minimal architecture the >> binary must run on. The compiler is free to use architecture-specific >> instructions. This flag behaves differently on Arm and x86. On Arm, -march >> does not override -mtune, but on x86 -march will override both -mtune and >> -mcpu. >> - -mtune=X: Tells the compiler to optimize for microarchitecture X but >> does not allow the compiler to change the ABI or make assumptions about >> available instructions. This flag has the more-or-less the same meaning on >> Arm and x86. >> - -mcpu=X: On Arm, this flag is a combination of -march and -mtune. It >> simultaneously specifies the target architecture and optimizes for a given >> microarchitecture. On x86 this flag is a deprecated synonym for -mtune. >> >> So maybe it makes sense to treat those flags behaves differently on >> different target . >> 3. I also tried llc to specific -mcpu and -attr (similar to -march, >> target-feature) in ARM, -attr will over write the default target-feature in >> -mcpu. >> >> on RISC-V, in sometime (or most?) we have same pipeline model but support >> different extension combination, > > I don't believe this to be correct. lowRISC's Ibex has a completely different > pipeline model to rocket, and there are countless other RISC-V cores with > different pipeline characteristics, including out-of-order pipeline > implementations like BOOM. I don't think we can favour one particular > scheduling model (beyond the generic ones we already default to). Yes, so lowRISC's Ibex need to use different pipleine model. I mention it just because in SiFive, the same serial core can share the same schedule model, but they have different isa extension. >> so I think maybe distinguishing the purpose of -mcpu and -march and make >> them with no interaction is a good idea. (behavior is equal to GCC) > > In LLVM, if you add `target-cpu` metadata to a function (which is added by > clang, based on `-mcpu`), that function will have all the features of that > CPU automatically added to it (as if you had used `-mattr` with all the > features in the model). If you don't add that metadata, a generic scheduling > model will be chosen. This suggests at the moment there can be no separation > between `-mtune` and `-march` as there is in GCC (without changes to the > target-independent parts of LLVM). thanks for reminding me, I re-implementation it. In D71124#1829998 <https://reviews.llvm.org/D71124#1829998>, @lenary wrote: > In D71124#1792216 <https://reviews.llvm.org/D71124#1792216>, @khchen wrote: > > > The problem is how `-mcpu` interact with explicitly specified `-march` (or > > target features). > > > > 1. in GCC, -mcpu is only used to chose the pipeline model, > > > I think you mean "in GCC, `-mtune` is only used to choose the pipeline model" > (`-mcpu` is not documented in the RISC-V specific GCC options documentation > <https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html>). > > Clang should attempt to maintain compatibility with GCC flags, but if they > only implement `-mtune`, then we have a little more freedom to do something > ergonomic with `-mcpu`. > > I'll note that clang already has a large TODO around implementing `-mtune` in > general, though the AArch64 backend seems to support it for some option > choices. > > > > > > > 2. I also read this > > <https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu> > > article talking about the X86 and ARM to handle those options. > > - -march=X: Tells the compiler that X is the minimal architecture the > > binary must run on. The compiler is free to use architecture-specific > > instructions. This flag behaves differently on Arm and x86. On Arm, > > -march does not override -mtune, but on x86 -march will override both > > -mtune and -mcpu. > > - -mtune=X: Tells the compiler to optimize for microarchitecture X but > > does not allow the compiler to change the ABI or make assumptions about > > available instructions. This flag has the more-or-less the same meaning on > > Arm and x86. > > - -mcpu=X: On Arm, this flag is a combination of -march and -mtune. It > > simultaneously specifies the target architecture and optimizes for a given > > microarchitecture. On x86 this flag is a deprecated synonym for -mtune. > > > > So maybe it makes sense to treat those flags behaves differently on > > different target . > > 3. I also tried llc to specific -mcpu and -attr (similar to -march, > > target-feature) in ARM, -attr will over write the default target-feature in > > -mcpu. > > > > on RISC-V, in sometime (or most?) we have same pipeline model but support > > different extension combination, > > I don't believe this to be correct. lowRISC's Ibex has a completely different > pipeline model to rocket, and there are countless other RISC-V cores with > different pipeline characteristics, including out-of-order pipeline > implementations like BOOM. I don't think we can favour one particular > scheduling model (beyond the generic ones we already default to). > > > so I think maybe distinguishing the purpose of -mcpu and -march and make > > them with no interaction is a good idea. (behavior is equal to GCC) > > In LLVM, if you add `target-cpu` metadata to a function (which is added by > clang, based on `-mcpu`), that function will have all the features of that > CPU automatically added to it (as if you had used `-mattr` with all the > features in the model). If you don't add that metadata, a generic scheduling > model will be chosen. This suggests at the moment there can be no separation > between `-mtune` and `-march` as there is in GCC (without changes to the > target-independent parts of LLVM). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71124/new/ https://reviews.llvm.org/D71124 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
