[cfe-dev] Option -mtune

[Arthur O'Dwyer via cfe-dev]

On Mon, Apr 20, 2020 at 4:05 AM Sjoerd Meijer via cfe-dev <
cfe-dev at lists.llvm.org> 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 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.
>

My naïve opinions FWIW:
- Personally I have never understood the difference between -target,
-march, -mcpu, and -mtune (particularly -march and -mtune). There are a lot
of blog posts out there (e.g.
https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/
 http://sdf.org/~riley/blog/2014/10/30/march-mtune/ ) indicating that I'm
not alone.  (Anyone got a really good resource on this topic?)
- It sounds like -mtune's behavior is not "falsifiable"; it can never
produce "wrong" code; it's purely an optimization option, like -O2. So
there is no practical difference, but there may be a psychological
difference, between saying "Clang permanently treats -mtune as a no-op"
versus "Clang has a remarkably low *quality of implementation* for -mtune,
and has no immediate plans to either improve or regress it."
- I don't think Clang should do anything actively to break
scripts/Makefiles that invoke both GCC and Clang as "$(CXX) -mtune=...".
That would be a downside with no upside.

my $.02,
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200420/2fcc324b/attachment.html>