[cfe-dev] Option -mtune

[Andrea Bocci via cfe-dev]

Hi Arthur,

On Mon, 20 Apr 2020 at 17:30, Arthur O'Dwyer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> - 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?)
>

from the GCC manual for the x86 target (
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/x86-Options.html#x86-Options ):

-march=cpu-type
>
> Generate instructions for the machine type cpu-type. In contrast to
> -mtune=cpu-type, which merely tunes the generated code for the specified
> cpu-type, -march=cpu-type allows GCC to generate code that may not run at
> all on processors other than the one indicated. Specifying -march=cpu-type
> implies -mtune=cpu-type.
>
> -mtune=cpu-type
>
> Tune to cpu-type everything applicable about the generated code, except
> for the ABI and the set of available instructions. While picking a specific
> cpu-type schedules things appropriately for that particular chip, the
> compiler does not generate any code that cannot run on the default machine
> type unless you use a -march=cpu-type option. For example, if GCC is
> configured for i686-pc-linux-gnu then -mtune=pentium4 generates code that
> is tuned for Pentium 4 but still runs on i686 machines.
>
> -mcpu=cpu-type
>
> A deprecated synonym for -mtune.
>

So, -march tells the compiler what instructions it can use, and thus sets a
kind of minimum requirements for running the generated binary; while -mtune
directs optimisation choices, but does not impact which CPUs can run the
binary.

Looking at the documentation for other targets like ARM and RISC-V, it
seems that the behaviour of -march and -mtune is consistent across them,
while in some cases -mcpu may specify additional flags.


- It sounds like -mtune's behavior is not "falsifiable"; it can never
> produce "wrong" code; it's purely an optimization option, like -O2.
>

Indeed.



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

True... I'd document it as a "no-op" :-)

Ciao,
.Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200420/e73d442e/attachment.html>