<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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);">
Please note that discussing user facing options on the list is not a waste of time. It's the opposite: changing and discussing the behaviour of user facing option requires consensus which is best achieved on the list, and not on a phabricator diff with a handful
of reviewers. A nice illustration is my first mail in this thread, and proposal to emit a diagnostic for a silently ignored option, which didn't get any buy in; no point in preparing a 2-lines patch for that.</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);">
Then we probably started to conflate a few things, and started discussing option handling in general, which is a very useful discussion to have. While options just work for some people and/or platforms/architectures, I think the pain is real for others. Summarising
this, the pain consists of minor points from silently ignoring options, to allowing invalid architecture combinations, no feedback to users, and seriously lacking documentation. </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>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Joerg Sonnenberger via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> 23 April 2020 01:53<br>
<b>To:</b> cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] Option -mtune</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Wed, Apr 22, 2020 at 12:12:40PM -0500, David Greene via cfe-dev wrote:<br>
> * -mcpu implies -target (based on host machine), -march and -mtune<br>
> <br>
> Example: -mcpu=skylake-avx512 sets<br>
> -target=x86_64-unknown-linux-gnu (when run on a Debian system)<br>
> -march=skylake-avx512<br>
> -mtune=skylake-avx512<br>
<br>
This is just wrong. The CPU name has no 1:1 mapping to target<br>
architectures. skylake-avx512 can still be happily used for<br>
i386-unknown-linux-gnu to completement your example. The reverse is<br>
somewhat true: the target triple can provide the default CPU<br>
(-march/-mcpu).<br>
<br>
> Of course one could always pass -triple (or other options) explicitly to<br>
> suppress the implied behaviors. We still want -mtune and -march to<br>
> operate independently of each other (i.e. neither implies the other) so<br>
> that one can generate backward-compatible binaries while still tuning<br>
> for recent microarchitectures.<br>
<br>
Please submit patches then for making scheduling independent of the<br>
architecture flags. Until then, this whole discussion seems to be a<br>
waste of time to me. Always using the/a default scheduling is IMO a<br>
perfectly sensible behavior and more often than not, what GCC is doing<br>
anyway.<br>
<br>
Joerg<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</span></font></div>
</body>
</html>