[PATCH] [AArch64] Implement Clang CLI interface proposal about "-march".

[Kevin Qin]

2014-07-01 16:17 GMT+08:00 Linaro Golin <renato.golin at linaro.org>:

> On 1 July 2014 04:05, Kevin Qin <kevinqindev at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140701/3823a676/attachment.html>