<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Fair enough, here's a draft patch to document this as a no-op: <a href="https://reviews.llvm.org/D78511" id="LPlnk395171">
https://reviews.llvm.org/D78511</a></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In this particular example, the latest question that led my post to the list, actually came from the ChromeOS team :) about the best options for a particular big-LITTLE configuration, also asking what the -mtune setting should be. But as I mentioned earlier,
just in general, this is tricky as it requires knowledge of the different cpus, its optional extensions, and what is actually implemented, and then this needs translations to the different compiler flags and options, so this is just a general problem that
many users struggle with. This is all further complicated by Clang's option handling, which for example accepts invalid architecture combinations, so users don't get proper feedback on their option settings. Within this context, I found silently ignoring -mtune
not really helpful and thought feedback to the user would be better. But I accept your argument, so put up this little doc change for review. And you're absolutely right that different things can be improved here too such as documentation and option handling.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers. <br>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> David Blaikie <dblaikie@gmail.com><br>
<b>Sent:</b> 20 April 2020 19:42<br>
<b>To:</b> Sjoerd Meijer <Sjoerd.Meijer@arm.com><br>
<b>Cc:</b> Peter Smith <Peter.Smith@arm.com>; cfe-dev@lists.llvm.org Developers <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] Option -mtune</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Mon, Apr 20, 2020 at 1:05 AM Sjoerd Meijer <<a href="mailto:Sjoerd.Meijer@arm.com">Sjoerd.Meijer@arm.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I understand the possible benefits of -mtune, but I just don't see how we benefit from a half baked implementation, or a no-op, and leaving the no-op in hoping that one day it will be implemented properly.<br>
</div>
</div>
</blockquote>
<div> </div>
<div>"I don't see how we benefit from <what's there today>" - I think we've already covered the practical benefit of command line compatibility. That's a fairly real/practical benefit & something that Clang does for lots of options, not only this one.<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="font-size:12pt">I also understand that removing the option could break some builds, but hey, compiler options and defaults change sometimes.
</span></div>
</div>
</blockquote>
<div><br>
Pretty rarely are flags outright removed or semantics changed in ways that would break builds, so far as I know.<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="font-size:12pt">In my opinion the cost of migrating would be worth the benefits. But I understand the different angles here, and hey, at least I've tried now...
</span><span id="x_gmail-m_375880992008535428��" style="font-size:12pt">:-)</span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
This is addressing the hard problem of setting optimal compiler options with -target, -march, -mcpu, and -mtune. In this equation -mtune is just a minor annoyance, but if we could get rid of this part of the confusion then that would be a good change to me
and avoid the regular question we get what the -mtune options should be.</div>
</div>
</blockquote>
<div><br>
It'd be interesting to understand the path your users go through that leads to confusion - what documentation (command line --help, websites (ones maintained/owned by your company, or Clang's open source/general website, etc), etc) & perhaps where more clarity
could be provided there.</div>
<div><br>
</div>
<div>- Daved<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Cheers.<br>
</div>
<div id="x_gmail-m_375880992008535428appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_gmail-m_375880992008535428divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Peter Smith <<a href="mailto:Peter.Smith@arm.com" target="_blank">Peter.Smith@arm.com</a>><br>
<b>Sent:</b> 20 April 2020 08:33<br>
<b>To:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>; Sjoerd Meijer <<a href="mailto:Sjoerd.Meijer@arm.com" target="_blank">Sjoerd.Meijer@arm.com</a>><br>
<b>Cc:</b> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> Developers <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [cfe-dev] Option -mtune</font>
<div> </div>
</div>
<div><font size="3" face="Times New Roman"><span style="font-size:12pt"><a name="x_m_375880992008535428_BM_BEGIN"></a>
<div><font size="2"><span style="font-size:11pt">I don't think that we could remove -mtune without breaking some builds that support both GCC and Clang with the same script, as -mtune is supported in GCC. As David points out -mtune isn't needed for correctness
so ignoring it for at least these types of project seems to be reasonable. An opt-in warning for accepted but ignored options could be an option though.<br>
<br>
IIRC We did use to have some support for mtune in AArch64, unfortunately we had to take it out (mea culpa
<a href="https://reviews.llvm.org/D39179" target="_blank">https://reviews.llvm.org/D39179</a>) as it wasn't just affecting micro-architectural features it was including architecture features as well. I think that there is some scope for putting back support
for mtune, it would need us to more cleanly separate out the micro-architectural features. The most recent post about this was
<a href="http://lists.llvm.org/pipermail/llvm-dev/2017-October/118520.html" target="_blank">
http://lists.llvm.org/pipermail/llvm-dev/2017-October/118520.html</a><br>
<br>
Peter<br>
<br>
________________________________________<br>
From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>> on behalf of Sjoerd Meijer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Sent: 19 April 2020 22:01<br>
To: David Blaikie<br>
Cc: <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> Developers<br>
Subject: Re: [cfe-dev] Option -mtune<br>
<br>
Thanks for your reply, and I can see that this is the only benefit of this no-op: if your move to Clang and if you still have -mtune set in your build environment, you don't get an "unknown option" error. But for me personally, silently ignoring things and
giving the impression it works is worse than a simple Makefile fix, but maybe I am wrong, which is why I checked here on the list. I was guessing that a diagnostic in this case would only be value if it's enabled by default as I'm afraid many users won't enable
it? And if you need to add a flag to get this diagnostic, you might as well get rid of -mtune?<br>
<br>
Cheers.<br>
<br>
________________________________<br>
From: David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
Sent: 19 April 2020 20:58<br>
To: Sjoerd Meijer <<a href="mailto:Sjoerd.Meijer@arm.com" target="_blank">Sjoerd.Meijer@arm.com</a>><br>
Cc: <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> Developers <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] Option -mtune<br>
<br>
On Sun, Apr 19, 2020 at 12:55 PM Sjoerd Meijer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
Hello,<br>
<br>
Quick question what you think we should be doing with option -mtune. Problem is that it looks like we support it because it is documented, it can be supplied on the command line, but it is silently ignored:<br>
<br>
// FIXME: Handle -mtune=.<br>
(void)Args.hasArg(options::OPT_mtune_EQ);<br>
<br>
giving the false impression to users it is doing something is probably the worst of options we have<br>
<br>
Not /the worst/ as such, many options are added to Clang so it's command line compatible (in the sense that you'll get a running program that behaves correctly) with GCC - I imagine the commit history of this feature probably justifies the addition with that
sort of reason.<br>
<br>
Seems quite reasonable for --help and web documentation to mention that it's a no-op/supported-for-compatibility flag.<br>
<br>
As for adding a warning for these sort of no-op flags, maybe? Probably opt-in, though.<br>
<br>
(we get regularly questions about this).<br>
We could simply remove it, or if this is too radical, issue a diagnostic that this is an unsupported option? Any thoughts/preferences?<br>
<br>
Cheers,<br>
Sjoerd.<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><mailto:<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</span></font></div>
</span></font></div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>