This is an archive of the discontinued LLVM Phabricator instance.

Change the default arm-linux-gnueabihf target to armv7
Needs ReviewPublic

Authored by sylvestre.ledru on Jun 26 2019, 1:28 AM.

Details

Summary

Changes the default from arm1176jzf-s (armv6) to cortex-a7

$ clang --target=arm-linux-gnueabihf -dM -E -xc - < /dev/null | grep "ARM_ARCH "
The goal is to change the default from:
#define __ARM_ARCH 6
to
#define __ARM_ARCH 7

Reported initially on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930008

Diff Detail

Event Timeline

sylvestre.ledru edited the summary of this revision. (Show Details)Jun 26 2019, 1:29 AM

If accepted, I will of course update the release notes

A test case missing for this change.

But more importantly, GCC and Clang work slightly differently with respect to default options. The current default arm1176jzf-s is old and somewhat arbitrary, but so is cortex-a7.

I think the rationale for arm1176jzf-s is that is the minimum that is always supported, and with -march and -mcpu can be more precise what you want to target.

But as this is a proposing a change in defaults , I think it's best if you also ask this question on the llvm dev list.

The arm1176jfz-s is what is used on the first revision of the Raspberry Pi and I think some of the later reduced size versions. This corresponds to the first mass market ARM linux distribution incorporating HF. Changing the default to ARMv7 would mean that people using clang for a Raspberry Pi using the default would end up with programs that likely would not run due to use of Arm v7 instructions. It is difficult to know how many people actually care about this as I suspect that Distros that still support the first revision of Raspberry Pi can change the default back. I think Sjoerd is right and a question on llvm-dev to canvas opinion would be a good idea.

If we were to go for Armv7 I also think that Cortex-a7 may not be the best choice. This is not the entry point for Armv7 as it includes the virtualization features but also looks like it has some code-generation tweaks to account for slow performance of certain instructions, this could result in slower performance for a later CPU. I'd prefer something equivalent to -march=armv7a -mcpu=generic.