GCC 8 Will Let You -march=native Correctly On ARM/AArch64

[phoronix]

Phoronix: GCC 8 Will Let You -march=native Correctly On ARM/AArch64

Linux developers and enthusiasts on x86_64 have long enjoyed the ability to use the -march=native option for having the GCC compiler attempt to auto-detect the CPU and set the appropriate microarchitecture flags. That support is finally being offered up for ARM with GCC 8...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-ARM

[AndyChow]

ARM is such a mess as a standard, I wonder how this will actually work in practice. You can mtune, but the mtune extensions don't work? ARM is a plague, RISC-V is the cure. You'll get an ISA string to define you march optimizations. We need some way to standardize gpu instructions also, which is a pain in ARM. A huge pain.

[carewolf]

ARM is such a mess as a standard, I wonder how this will actually work in practice. You can mtune, but the mtune extensions don't work? ARM is a plague, RISC-V is the cure. You'll get an ISA string to define you march optimizations. We need some way to standardize gpu instructions also, which is a pain in ARM. A huge pain.

Yeah. Though if they actually got runtime detection working on ARM, they could also enable function versioning which uses a copy of the same code to chose optimized functions at runtime. But it probably isn't complete. You can detect several features using hwcap, but unfortunately far from all, and not the architecture to tune for.

[numacross]

what's AArch64? I think, in order to confuse people as much as possible, Linux should have its own obfuscated names for everything. Why be like Apple and Android and call it arm64? That won't make the technogeeks at Red Hat feel smarter than everyone else!

AArch64 is the execution state of the Armv8.x (Armv8-A) architecture implementing the A64 instruction set. An equivalent in x86-64 (amd64) is the 64-bit submode of the long mode.

Edit: To clarify - it's just the 64-bit part of "arm64" since it can execute in both 64- and 32- modes.

[ldesnogu]

ARM is such a mess as a standard, I wonder how this will actually work in practice. You can mtune, but the mtune extensions don't work? ARM is a plague, RISC-V is the cure. You'll get an ISA string to define you march optimizations. We need some way to standardize gpu instructions also, which is a pain in ARM. A huge pain.

RISC-V is the cure of nothing as far as toolchains go. It will face the MIPS mess with compilers (and software in general) due to the possibility of proprietary extensions. Been there on MIPS (R5900 of the PS2 as an example) and it looks like RISC-V will follow that path.

[carewolf]

what's AArch64? I think, in order to confuse people as much as possible, Linux should have its own obfuscated names for everything. Why be like Apple and Android and call it arm64? That won't make the technogeeks at Red Hat feel smarter than everyone else!

Not a Linux invention. It is an ARM invention, they decided to call their new 64-bit architecture AArch.. In fact they made two, there is both an AArch32 and AArch64, and AArch32 is NOT the same as Arm<v7. In fact just to make things MORE confusing there is are ARMv8 extension for the legacy ARM mode that are separate from AArch32 and AArch64...

As we said ARM is doing all they can to make things confusing which is what makes the feat by gcc so impressive.

[jacob]

Seriously, I love ARM's unbeatable performance/cost/consumption tradeoff, but as an architecture it's such a mess that it makes good old x86 look straightforward in comparison.

[grok]

RISC-V is the cure of nothing as far as toolchains go. It will face the MIPS mess with compilers (and software in general) due to the possibility of proprietary extensions. Been there on MIPS (R5900 of the PS2 as an example) and it looks like RISC-V will follow that path.

Or, the standard instruction sets will keep you busy anyway?
https://en.wikipedia.org/wiki/RISC-V...and_Extensions
Funny how you can have without FPU, but also without integer multiply!
I doubt it will run end user software in the near term (i.e. phone or laptop main CPU) but it may be big in controllers. CPU are in everything no matter how quaint, e.g. keyboard or mono bluetooth speaker. May get into a low end router, a one-drive NAS, etc.

A "full" (for consumers) computer seems longer term. The competition has all that stuff like SIMD, hardware crypto and even hypervisor support that isn't that "useless" either!

[grok]

Seriously, I love ARM's unbeatable performance/cost/consumption tradeoff, but as an architecture it's such a mess that it makes good old x86 look straightforward in comparison.

Well, "AArch" throws out old stuff?
I mean, perhaps a lot of stuff lingers, but take x86-64 in "long mode" : the 8086, 186, 286 and VM86 stuff aren't available.
So you can ignore it sort of..

(Yea what about the 186, or the compatible NEC V30. Perhaps someone can do a tiny DOS computer with VGA, SD and Sound Blaster with that, like those C64 or Amiga on FPGA projects. Then you'd have a sort of understandable PC)

[ldesnogu]

Seriously, I love ARM's unbeatable performance/cost/consumption tradeoff, but as an architecture it's such a mess that it makes good old x86 look straightforward in comparison.

I agree that ten years ago it was kind of messy (though nothing compared to the braindead x86). But things are much better now. What do you find messy?