<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 22, 2020 at 1:49 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">Sjoerd Meijer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> writes:<br>
<br>
> This is addressing the hard problem of setting optimal compiler<br>
> options with -target, -march, -mcpu, and -mtune.  In this equation<br>
> -mtune is just a minor annoyance, but if we could get rid of this part<br>
> of the confusion then that would be a good change to me and avoid the<br>
> regular question we get what the -mtune options should be.<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></blockquote><div><br></div><div>As mentioned before, being compatible with GCC is a <i>huge</i> 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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It doesn't help that these options aren't very well documented:<br>
<br>
<a href="https://clang.llvm.org/docs/UsersManual.html#target-specific-features-and-limitations" rel="noreferrer" target="_blank">https://clang.llvm.org/docs/UsersManual.html#target-specific-features-and-limitations</a><br>
<br>
-target is barely mentioned for CPUs and there is certainly no<br>
indication that one needs -target to make -mcpu/-mtune do something<br>
useful.</blockquote><div><br></div><div>Better documentation would definitely be good, in this and many other areas Clang is entirely dependent upon GCC's documentation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Contrast that with gcc's extensive documentation of tuning parameters:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Submodel-Options.html#Submodel-Options" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Submodel-Options.html#Submodel-Options</a><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</blockquote><div><br></div><div>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:</div><div>   clang -target $TRIPLE -mcpu $CPU</div><div>instead of building a brand new GCC targeting $TRIPLE, called $TRIPLE-gcc, and then running:</div><div>   $TRIPLE-gcc -mcpu $CPU</div><div>(of course, sometimes using -march instead of -mcpu, depending on the triple...)</div><div><br></div><div></div></div></div>