[cfe-dev] Option -mtune

[David Blaikie via cfe-dev]

On Sun, Apr 26, 2020 at 3:32 PM David Greene via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> James Y Knight via cfe-dev <cfe-dev at lists.llvm.org> writes:
>
> >> Honestly, the whole system needs an overhaul:
> >>
> >>
> http://clang-developers.42468.n3.nabble.com/Behavior-of-mcpu-td4064178.html
> >>
> >> I noticed this odd difference in behavior based on target.  In the end
> >> the answer was, "We want to behave like gcc," but that is not a very
> >> compelling argument to me.  Yes "-m" options are machine-specific, but
> >> giving the same option with the same name different behaviors is
> >> non-intuitive.
> >>
> >
> > As mentioned before, being compatible with GCC is a *huge* advantage for
> > clang. I agree that it's quite unfortunate that the march/mcpu/mtune set
> of
> > options are so divergent in behavior between targets.
>
> But we're already incompatible because we require -target to do
> cross-compiling.  Yes, gcc is not natively a cross compiler so you have
> to do special builds for that so I understand why -target exists.
>
> And what do we mean by "compatible" in this context.  Do we mean the
> options are accepted (they absolutely should be) or do we mean we match
> gcc behavior exactly.


The original proposal of this thread was to remove -mtune, which would
break compatibility even in a non-cross-compiling scenario, where
compatibility exists today.


>   I would submit that we should *not* do the latter
> but rather do something better.
>

Sure - patches to improve the situation are welcome, I'm sure. Improving
the documentation, implementing -mtune functionality (rather than it just
being a no-op), etc. But the original proposal of the thread, removing
-mtune, seems to break existing compatibility in an unfavorable way.


>
> Right now I am not able to gather a list of what -march/-mcpu/-mtune do
> for each target because it's not documented anywhere.  The best I could
> do is consult the gcc documentation and *assume* clang does the same.
>
> Would it be helpful to gather a description of what these flags do in
> gcc for the targets clang supports and present a summary of the current
> gcc state with a proposal of what clang might do better?
>
> Because right now what we have is honestly quite difficult to use.
>
> >> Given the way -target works, we're already incompatible with gcc (gcc
> >> with happily cross-compile/tune with -mcpu), so why not just do the
> >> Right Thing and make these options behave uniformly across targets?  In
> >> my mind it should be something like this
> >
> >
> > GCC does _not_ support using -mcpu to switch the target, you need to
> > compile an entirely new GCC. Clang follows the same scheme as GCC does,
> > except that you run:
> >    clang -target $TRIPLE -mcpu $CPU
> > instead of building a brand new GCC targeting $TRIPLE, called
> $TRIPLE-gcc,
> > and then running:
> >    $TRIPLE-gcc -mcpu $CPU
> > (of course, sometimes using -march instead of -mcpu, depending on the
> > triple...)
>
> Yes I know that and I apologize for my clumsy wording.  I was trying to
> point out that if someone is cross compiling, the options passed to a
> cross-gcc already differ from the options passed to clang because clang
> needs --target.  The user already needs to adjust build systems for gcc
> vs. clang builds.
>
>                      -David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200426/327c1082/attachment-0001.html>