[PATCH 7/7][LoongArch] Opcodes support

[Fangrui Song]

> +static struct loongarch_opcode loongarch_macro_opcodes[] =
> +{
> [...]
> +  { 0, 0, "la.pcrel", "r,la",
> +    "pcaddu12i %1,%%pcrel(%2+0x800)>>12;"
> +    "addi.d %1,%1,%%pcrel(%2+4)-(%%pcrel(%2+4+0x800)>>12<<12);",
> +    &LARCH_opts.addrwidth_is_64, 0, 0 },
> +  { 0, 0, "la.pcrel", "r,r,la",
> +    "pcaddu12i %1,(%%pcrel(%3)-(%%pcrel(%3+0x80000000)>>32<<32))<<32>>44;"
> +    "ori %2,$r0,(%%pcrel(%3+4)-(%%pcrel(%3+4+0x80000000)>>32<<32))&0xfff;"
> +    "lu32i.d %2,%%pcrel(%3+8+0x80000000)<<12>>44;"
> +    "lu52i.d %2,%2,%%pcrel(%3+12+0x80000000)>>52;"
> +    "add.d %1,%1,%2;",
> +    &LARCH_opts.addrwidth_is_64, 0, 0 },
> +
> +  { 0, 0, "la.got", "r,l",
> +    "pcaddu12i %1,(%%pcrel(_GLOBAL_OFFSET_TABLE_+0x800)+%%gprel(%2))<<32>>44;"
> +    "ld.w "
> +    "%1,%1,%%pcrel(_GLOBAL_OFFSET_TABLE_+4)+%%gprel(%2)-((%%pcrel(_GLOBAL_"
> +    "OFFSET_TABLE_+4+0x800)+%%gprel(%2))>>12<<12);",
> +    &LARCH_opts.addrwidth_is_32, 0, 0 },

Relocations don't need support for arbitrary shifts.  Just hard code the
possible shift variants and the implementation will be much cleaner, no
need for a long list of R_LARCH_SOP_PUSH_*.

See xen0n's comment on https://github.com/loongson/LoongArch-Documentation/pull/3#issuecomment-894672071

> Plus it seems there's a stack machine implemented with relocation records. I think this is bad for these reasons:
> 
> Fragility could ensue due to tools not respecting relative order of relocation records on the same address;
> It's superficial, conveying actions and not motivations, which is generally bad smell in software engineering;
> Not much complexity is shed by the introduction of intended flexibility here, so it wasn't exactly profitable either;
> No prior cases wheresoever found in public code, so it's not sure if the scheme is to be appreciated universally.

Tests nearly do not exist. There is only a nop test.

% ls gas/testsuite/gas/loongarch/
nop.d  loongarch.exp  nop.s