[cfe-dev] Compiling ARM code at an architecture level

[Renato Golin]

On 11 February 2015 at 00:43, Meador Inge <meadori at gmail.com> wrote:
>   $ 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. :)

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... :(

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... :/

cheers,
--renato