2014-07-01 16:17 GMT+08:00 Linaro Golin <[email protected]>: > On 1 July 2014 04:05, Kevin Qin <[email protected]> wrote: > > I only got it removed from AArch64 target. Gcc has deprecated this option > > for a while, and I don't know any tools or build systems reply on this > > option. If there's demand of this option, I can add it back and provide a > > warning on it, just like "-mcpu". > > Deprecated or removed? I'd be surprised if the latter. > > I'm not expecting new software to use deprecated options, but old > build systems that can be made to build on AArch64 by just changing > the triple will still use all the legacy options in hidden places > which will extend the usage of -mcpu well beyond AArch64. > > It's deprecated. Any use of "-mfpu" on AArch64 target will provide an warning "argument unused during compilation" and won't block compiling process. So most build systems can still work well except receiving a lot of warnings.
> I didn't explain it clearly. Your point is totally what I did in this > patch. > > I emphasize " ONLY get micro-architecture level feature enabled" is want > to > > say ISA won't be changed by this option. This option is to select target > CPU > > to optimize for, including enabling micro-architecture level feature, > > choosing MI scheduler and triggering any optimizations specific for > target. > > Oh, I see. My bad. > > > > In my patch, the difference between "-mcpu" and "-mtune" is that, "-mcpu" > > will enable all ISAs which target CPU supports, while "-mtune" won't do > > this. > > This is correct. > > > > And "-mcpu" can accept extra feature modifiers to make a change, but > > "-mtune" accepts CPU name only. > > This is new, and since we're trying to discourage the usage of -mcpu, > a little in the wrong direction. We shouldn't make it *more* > convenient for people to use -mcpu... > It's to get compatible with gcc. And one day if there's multiple versions of a cpu with different architectural extensions, this kind of modifier can help to make a choice. > > > So "-mcpu" is an shortcut of "-march" and "-tune". > > Which seems to be the case in GCC, too. > > > > Keeping this option alive in clang is because it's still alive in > > gcc, and may still be used in many projects. An warning is added to > > discourage use of this option. > > I agree with this, but if GCC doesn't have the features in -mcpu, I > don't think we should add it, since the only reason we do is for > compatibility with legacy GCC options. > Gcc can accept "-mcpu" with modifiers. > > > > They don't need to complain > > typing too much as splitting "-mcpu" into "-march" and "-mtune" because > they > > can use "-mtune" only. > > Maybe they do... :) > > The reason why you need -mcpu is (AFAIK) *only* because you haven't > specified your arch correctly. So, if you specify "-march arm", you'll > need to specify your CPU to generate anything other than ARMv4 code, > since -mtune won't help. If you specify "armv7", you'll need "-mcpu > cortex-m4" to get M-class, and so on. But if you choose "armv7a", you > only need -mtune to make it faster on A9, or "armv7ave" to mean > virt+hdiv, than it's obvious A15-class, which you'll need -mtune to > make it faster on A15 and not A7. > > All in all, -mcpu is redundant if the arch is correct. I believe GCC > understands quite well all the ARM arch strings, and Clang/LLVM should > if it doesn't. > > And with the features in -march (armv7a+noneon), it'd be even less > important to have a "-mcpu tegra3" option. > > Makes sense? > Agreed. If there's more than one architecture available in AArch64 target, "-march" will be more important than "-mtune", as it is specifying the base ISAs to generate. But it's still reasonable to provide a default architecture and default feature sets if "-march" isn't used. Using "-mtune" only can work well at moment, but I can't guarantee this when more architecture introducing. So be used to type "-march" is a good habit. I leave this message here is to attract some lazy user(like me) and provide convenience for some quick experiment:) > cheers, > --renato > -- Best Regards, Kevin Qin
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
