[cfe-commits] [llvm-commits] The AArch64 LLVM (& Clang) target

[Tim Northover]

> +++ b/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
> +// FIXME: Better way. Surely TableGen can generate these LLVM <-> Architectural
> +// mappings. See also MCTargetDesc/AArch64BaseInfo.h.
> +static const unsigned GPR64DecoderTable[] = {
> +  AArch64::X0, AArch64::X1, AArch64::X2, AArch64::X3,
> +  AArch64::X4, AArch64::X5, AArch64::X6, AArch64::X7,
> +  AArch64::X8, AArch64::X9, AArch64::X10, AArch64::X11,
> +  AArch64::X12, AArch64::X13, AArch64::X14, AArch64::X15,
> +  AArch64::X16, AArch64::X17, AArch64::X18, AArch64::X19,
> +  AArch64::X20, AArch64::X21, AArch64::X22, AArch64::X23,
> +  AArch64::X24, AArch64::X25, AArch64::X26, AArch64::X27,
> +  AArch64::X28, AArch64::X29, AArch64::X30, AArch64::XZR
> +};
>
> It certainly can, and it does. Use MCRegisterInfo::getEncodingValue() and MCRegisterClass::getRegister().

I've just noticed that this introduces a potential layering violation
(I'm a little hazy on what layers we're trying to maintain within the
backends).

Basically, GPR64RegClass is defined in libLLVMAArch64CodeGen. llvm-mc
and llvm-objdump don't seem to care about this, but I could see a
minimal disassembler getting a bit upset.

Does anyone know if how big an issue this is; and what the ideal
solution would be? Put the MCRegisterClass bits into
libLLVMAArch64Desc (by modifying TableGen)?

Cheers.

Tim.