[cfe-dev] Option -mtune

Mon Apr 20 01:05:30 PDT 2020

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 also understand that removing the option could break some builds, but hey, compiler options and defaults change sometimes. 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.

Cheers.
________________________________
From: Peter Smith <Peter.Smith at arm.com>
Sent: 20 April 2020 08:33
To: David Blaikie <dblaikie at gmail.com>; Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: cfe-dev at lists.llvm.org Developers <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> on behalf of Sjoerd Meijer via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 19 April 2020 22:01
To: David Blaikie
Cc: 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>
Sent: 19 April 2020 20:58
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: cfe-dev at lists.llvm.org Developers <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>> 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>
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/eac40882/attachment.html>