[cfe-dev] [RFC] Make "requires arm" also include AArch64 in module map files

Renato Golin renato.golin at linaro.org
Fri Jul 24 03:34:26 PDT 2015


On 23 July 2015 at 22:38, Ben Langmuir <blangmuir at apple.com> wrote:
> For “arm”:
> * The closest I found is that GCC has a function attribute "target(arm)” that means to use the “A32” ISA, but this is to distinguish it from thumb (T32), not from aarch64/A64 it looks like.
> * I don’t think this should stop us from using “arm” to mean arm32 || arm64.

"arm" has been used to mean the architecture, as well as the
instruction set. Since Thumb operates on the same registers, flags and
can inter-operate with ARM, including Thumb in "arm" is reasonable.
Even v8 AArch32, which has some small differences, is an acceptable
match for "arm". So much so that they're all in the same back-end on
all compilers.

But AArch64 is quite a different beast. They're in completely separate
worlds. Even though AArch64 has a compatibility mode (AArch32), it may
not be usable if the system is not setup properly (4K pages instead of
64K pages). So, if joining both in the same modules means sometimes
AArch32 code will be selected during 64-bit execution, this may break
many things. The other way around will *never* work.

I don't think we should get "arm" to mean AArch64.


> For “arm32”:
> * I made this name up, and haven’t found any useful precedent for this or any other name.  The ISA is called A32, but I think the T32 ISA would also count as “arm32” in my scheme…

I'm not a big fan of "arm32" either, probably because I don't think
"arm" should ever mean AArch64. I'd recommend you have a good talk
with the ARM guys before any naming decision.


> * Since no is actually asking for this feature, I suppose we could just not add it. Users who wanted arm32 could say “requires arm, !aarch64” for now and we could reconsider this once there is motivation

Expectation vs reality. When I "import arm", I expect to get ARM,
maybe even Thumb, but never AArch64.

cheers,
-renato




More information about the cfe-dev mailing list