Compiling ARM code at an architecture level

Hi All,

I am working on a problem where it does not seem possible to
compile code for ARM at an architecture level. For example,
compiling:

$ clang -target arm-none-eabi -mthumb -march=armv7 -o - -S test.c | grep ‘.cpu’
.cpu cortex-a8

However, I don’t want the code locked to a Cortex-A8 CPU. In fact, for this particular
example it can cause problems because I would like to create an ARMv7 Thumb static
library that can be used with both ARMv7 A and M profiles.

GCC has logic to produce a .arch directive when -march is used:

$ arm-none-eabi-gcc -mthumb -march=armv7 -S -o - test.c | grep ‘.cpu’
$ arm-none-eabi-gcc -mthumb -march=armv7 -S -o - test.c | grep ‘.arch’
.arch armv7

I would like similar behavior in Clang.

From working through the various toolchains and options in the driver code I
see two immediate approaches:

  1. When -mcpu is not specified, don’t generate -target-cpu for the CC1 invocation
    and derive the architecture information from the triple (I did find it somewhat
    surprising the architecture version info in embedded in the triple). Wether or
    not the CPU string is empty will detail if .cpu or .arch should be generated.

  2. Add driver support for the GCC ARM -mcpu=generic-arch option form. Then
    we can still always generate -target-cpu still and make decisions on whether
    to generate .cpu or .arch from the “generic-” part.

Have other run into this and consider it a problem? Other solutions?

– Meador

  $ arm-none-eabi-gcc -mthumb -march=armv7 -S -o - test.c | grep '\.cpu'
  $ arm-none-eabi-gcc -mthumb -march=armv7 -S -o - test.c | grep '\.arch'
      .arch armv7

I would like similar behavior in Clang.

Hi Meador,

Indeed, that would be a better solution, and it would have to be
communicated between Clang and LLVM. I believe the biggest issue right
now would be to get Clang's driver to not assume the minimum v7A core
as the default for "armv7", only for "armv7a", and to get LLVM's
back-end to emit the .arch if no cpu is specified.

Right now, Clang's driver is a bit crap on getting the triples/cpu/fpu
right, so that could take a while.

   2. Add driver support for the GCC ARM -mcpu=generic-arch option form.
Then
       we can still always generate -target-cpu still and make decisions on
whether
       to generate .cpu or .arch from the "generic-" part.

That would be an ugly workaround in multiple compilers for an already
ugly implementation in one compiler (clang). Not to mention that you'd
upset the gcc community for a problem that is clearly in Clang. :slight_smile:

We have tried improving the driver to be better at this for the last 5
years with little success, and with increasing complexity, the costs
of doing so will only increase. I have a plan to work on how cpus and
fpus are parsed, which could help you in the long term (by making the
refactoring simpler), but even that I'm finding hard to get to... :frowning:

However, I can't think of any quick solution to your problem other
then compile it twice using armv7a and armv7m for -march.

Sorry if that sounds negative, but there seems to not be enough
interest in the rest of the community to make this refactoring a
priority, so it'll probably happen slower than you'd want... :confused:

cheers,
--renato

That would be an ugly workaround in multiple compilers for an already
ugly implementation in one compiler (clang). Not to mention that you'd
upset the gcc community for a problem that is clearly in Clang. :slight_smile:

FWIW, the -mcpu=generic-arch for is already supported in GCC. I should
have been clearer about that:

* ARM Options - Using the GNU Compiler Collection (GCC)

We have tried improving the driver to be better at this for the last 5
years with little success, and with increasing complexity, the costs
of doing so will only increase. I have a plan to work on how cpus and
fpus are parsed, which could help you in the long term (by making the
refactoring simpler), but even that I'm finding hard to get to... :frowning:

I am interested in hearing more about that and could possibly help.

However, I can't think of any quick solution to your problem other
then compile it twice using armv7a and armv7m for -march.

Sorry if that sounds negative, but there seems to not be enough
interest in the rest of the community to make this refactoring a
priority, so it'll probably happen slower than you'd want... :confused:

Not negative, just the facts :slight_smile: Thanks for the reply!

-- Meador