Open ktkachov opened 1 month ago
CC: @pratlucas , @ostannard , @vhscampos
@llvm/issue-subscribers-backend-aarch64
Author: Kyrill Tkachov (ktkachov)
@tmatheson-arm @DavidSpickett @jthackray FYI
This sounds like a sensible thing to add to me, if it works the same as -mcpu=native. You could argue that it should work the same way as other -march options where it enables the architecture features, but not the tuning for a specific cpu. Having it work the same way as GCC sounds most sensible to me though.
It doesn't look like the GCC documentation was ever updated to reflect this: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
At least, it is more ambiguous than the x86 docs: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
Yeah that's fair. It was just an oversight in the documentation. I'll update the GCC documentation separately
You could argue that it should work the same way as other -march options where it enables the architecture features, but not the tuning for a specific cpu.
I also thought this but the other side is that the CPU's characteristics are part of the "native" architecture, so they should be accounted for I think.
Maybe it'd be awkward for a big/little system where the extensions match but the lower level details don't? Though I think you'd be better off spelling out -march=armX.Y-a+a+b+c
to get exactly what you want anyway. It's not really "native" if you're going to share it between different cores, even if they are superficially the same.
From the GCC doc for x86:
This selects the CPU to generate code for at compilation time by determining the processor type of the compiling machine. Using -march=native enables all instruction subsets supported by the local machine (hence the result might not run on different machines). Using -mtune=native produces code optimized for the local machine under the constraints of the selected instruction set.
This says that -march=native
enables only extensions, and -mtune=native
tunes code generation. Is that actually what was implemented? Seems like AArch64 might have diverged if so.
-march and -mcpu have different meanings on x86 than aarch64 anyway (-march is recommended on x86 and -mcpu is recommended on aarch64). The GCC documentation for aarch64 -march=native is updated to be more explicit about treat -march=native as -mcpu=native now: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#index-march
Generally speaking, -mcpu=native is the recommended option for native AArch64 Linux users for getting the best CPU and architecture-specific performance out of their code. However, many makefiles out there are geared towards a default x86 environment and use -march=native, which is the recommended option on that target. To help with aarch64 porting for those users and avoid them having to special-case aarch64, we could treat -march=native as -mcpu=native. That is, select not just the architecture features of the host system, but also select the host CPU through the part number and tune for it in codegen. This will keep the contract of -march=native while providing a better performance experience for the users and help with porting. GCC does this since GCC 13 https://gcc.gnu.org/g:dd9e5f4db2debf1429feab7f785962ccef6e0dbd