<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 26, 2020 at 3:32 PM David Greene via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> writes:<br>
<br>
>> Honestly, the whole system needs an overhaul:<br>
>><br>
>> <a href="http://clang-developers.42468.n3.nabble.com/Behavior-of-mcpu-td4064178.html" rel="noreferrer" target="_blank">http://clang-developers.42468.n3.nabble.com/Behavior-of-mcpu-td4064178.html</a><br>
>><br>
>> I noticed this odd difference in behavior based on target.  In the end<br>
>> the answer was, "We want to behave like gcc," but that is not a very<br>
>> compelling argument to me.  Yes "-m" options are machine-specific, but<br>
>> giving the same option with the same name different behaviors is<br>
>> non-intuitive.<br>
>><br>
><br>
> As mentioned before, being compatible with GCC is a *huge* advantage for<br>
> clang. I agree that it's quite unfortunate that the march/mcpu/mtune set of<br>
> options are so divergent in behavior between targets.<br>
<br>
But we're already incompatible because we require -target to do<br>
cross-compiling.  Yes, gcc is not natively a cross compiler so you have<br>
to do special builds for that so I understand why -target exists.<br>
<br>
And what do we mean by "compatible" in this context.  Do we mean the<br>
options are accepted (they absolutely should be) or do we mean we match<br>
gcc behavior exactly.</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  I would submit that we should *not* do the latter<br>
but rather do something better.<br></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Right now I am not able to gather a list of what -march/-mcpu/-mtune do<br>
for each target because it's not documented anywhere.  The best I could<br>
do is consult the gcc documentation and *assume* clang does the same.<br>
<br>
Would it be helpful to gather a description of what these flags do in<br>
gcc for the targets clang supports and present a summary of the current<br>
gcc state with a proposal of what clang might do better?<br>
<br>
Because right now what we have is honestly quite difficult to use.<br>
<br>
>> Given the way -target works, we're already incompatible with gcc (gcc<br>
>> with happily cross-compile/tune with -mcpu), so why not just do the<br>
>> Right Thing and make these options behave uniformly across targets?  In<br>
>> my mind it should be something like this<br>
><br>
><br>
> GCC does _not_ support using -mcpu to switch the target, you need to<br>
> compile an entirely new GCC. Clang follows the same scheme as GCC does,<br>
> except that you run:<br>
>    clang -target $TRIPLE -mcpu $CPU<br>
> instead of building a brand new GCC targeting $TRIPLE, called $TRIPLE-gcc,<br>
> and then running:<br>
>    $TRIPLE-gcc -mcpu $CPU<br>
> (of course, sometimes using -march instead of -mcpu, depending on the<br>
> triple...)<br>
<br>
Yes I know that and I apologize for my clumsy wording.  I was trying to<br>
point out that if someone is cross compiling, the options passed to a<br>
cross-gcc already differ from the options passed to clang because clang<br>
needs --target.  The user already needs to adjust build systems for gcc<br>
vs. clang builds.<br>
<br>
                     -David<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>