[cfe-dev] Option -mtune

[Fangrui Song via cfe-dev]

On 2020-04-24, David Greene via cfe-dev wrote:
>Joerg Sonnenberger via cfe-dev <cfe-dev at lists.llvm.org> writes:
>
>>> * -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).
>
>Fair enough, but for my own education, in what situation would
>skylake-avx512 be used with i386-unknown-linux-gnu?

CPU->target triple mapping gets more complex when more "OSes" and "environments" are concerned.
For example, on ARM there are eabi, gnueabi, gnueabihf, musleabi, musleabihf, etc.

If LLVM_DEFAULT_TARGET_TRIPLE says the environment is currently
"powerpc64le-linux-musl",
it might make sense to use {i686,x86_64}-linux-musl if -mcpu specifies an x86 cpu.

To get proper cross compilation experience with -mcpu just working,
ln -s /path/to/clang aarch64-unknown-linux-clang
./aarch64-unknown-linux-clang -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.
>
>It's not a waste of time to improve the user experience.  Part of the
>problem is that it's not at all clear what the "architecture flags" do.
>It seems like we'd want to decide that before changing things.
>
>                       -David
>_______________________________________________
>cfe-dev mailing list
>cfe-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev