[cfe-dev] Option -mtune

[Sjoerd Meijer via cfe-dev]

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.

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.

Cheers.
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Joerg Sonnenberger via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 23 April 2020 01:53
To: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Option -mtune

On Wed, Apr 22, 2020 at 12:12:40PM -0500, David Greene via cfe-dev wrote:
> * -mcpu implies -target (based on host machine), -march and -mtune
>
>   Example: -mcpu=skylake-avx512 sets
>     -target=x86_64-unknown-linux-gnu (when run on a Debian system)
>     -march=skylake-avx512
>     -mtune=skylake-avx512

This is just wrong. The CPU name has no 1:1 mapping to target
architectures. skylake-avx512 can still be happily used for
i386-unknown-linux-gnu to completement your example. The reverse is
somewhat true: the target triple can provide the default CPU
(-march/-mcpu).

> Of course one could always pass -triple (or other options) explicitly to
> suppress the implied behaviors.  We still want -mtune and -march to
> operate independently of each other (i.e. neither implies the other) so
> that one can generate backward-compatible binaries while still tuning
> for recent microarchitectures.

Please submit patches then for making scheduling independent of the
architecture flags. Until then, this whole discussion seems to be a
waste of time to me. Always using the/a default scheduling is IMO a
perfectly sensible behavior and more often than not, what GCC is doing
anyway.

Joerg
_______________________________________________
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/20200423/dd41ca3a/attachment-0001.html>