[cfe-dev] Option -mtune

Mon Apr 20 12:26:45 PDT 2020

Fair enough, here's a draft patch to document this as a no-op: https://reviews.llvm.org/D78511

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.

Cheers.

________________________________
From: David Blaikie <dblaikie at gmail.com>
Sent: 20 April 2020 19:42
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: Peter Smith <Peter.Smith at arm.com>; cfe-dev at lists.llvm.org Developers <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Option -mtune

On Mon, Apr 20, 2020 at 1:05 AM Sjoerd Meijer <Sjoerd.Meijer at arm.com<mailto:Sjoerd.Meijer at arm.com>> wrote:
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.

"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.

I also understand that removing the option could break some builds, but hey, compiler options and defaults change sometimes.

Pretty rarely are flags outright removed or semantics changed in ways that would break builds, so far as I know.

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... :-)
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.

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.

- Daved

Cheers.
________________________________
From: Peter Smith <Peter.Smith at arm.com<mailto:Peter.Smith at arm.com>>
Sent: 20 April 2020 08:33
To: David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>>; Sjoerd Meijer <Sjoerd.Meijer at arm.com<mailto:Sjoerd.Meijer at arm.com>>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> Developers <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: Re: [cfe-dev] Option -mtune

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.

IIRC We did use to have some support for mtune in AArch64, unfortunately we had to take it out (mea culpa https://reviews.llvm.org/D39179) 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 http://lists.llvm.org/pipermail/llvm-dev/2017-October/118520.html

Peter

________________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 19 April 2020 22:01
To: David Blaikie
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> Developers
Subject: Re: [cfe-dev] Option -mtune

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?

Cheers.

________________________________
From: David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>>
Sent: 19 April 2020 20:58
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com<mailto:Sjoerd.Meijer at arm.com>>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> Developers <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: Re: [cfe-dev] Option -mtune

On Sun, Apr 19, 2020 at 12:55 PM Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org><mailto:cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>> wrote:
Hello,

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:

  // FIXME: Handle -mtune=.
  (void)Args.hasArg(options::OPT_mtune_EQ);

giving the false impression to users it is doing something is probably the worst of options we have

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.

Seems quite reasonable for --help and web documentation to mention that it's a no-op/supported-for-compatibility flag.

As for adding a warning for these sort of no-op flags, maybe? Probably opt-in, though.

(we get regularly questions about this).
We could simply remove it, or if this is too radical, issue a diagnostic that this is an unsupported option? Any thoughts/preferences?

Cheers,
Sjoerd.

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org><mailto:cfe-dev at lists.llvm.org<mailto: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/20200420/9e79d9d6/attachment-0001.html>