Background

We currently have the following list of values for target_arch:

• aarch64
• amdgpu
• arm
• arm64ec
• avr
• bpf
• csky
• hexagon
• loongarch32
• loongarch64
• m68k
• mips
• mips32r6
• mips64
• mips64r6
• msp430
• nvptx64
• powerpc
• powerpc64
• riscv32
• riscv64
• s390x
• sparc
• sparc64
• wasm32
• wasm64
• x86
• x86_64
• xtensa

Often you want to configure the 32- and 64-bit versions of an arch the same, such as x86-32 and x86-64. The way to do this currently is with cfg(any(target_arch = "x86", target_arch = "x86_64")) but this gets repetitive, especially with targets like MIPS that have more than two possible values for target_arch.

(Inspired by #t-compiler > mipsr6 targets `target_arch` confusion)

Proposal

Add a number of new target_family values intended to group targets with similar 32- and 64-bit arch variants, as well as within similar 32- and 64-bit arches (only applicable on MIPS). This is what we already do on Wasm. Similar defines set by Clang are provided for reference, from https://c.godbolt.org/z/a66Yx7Pqb.

New cfg:

target_family="arm":

• arm (clang: __arm__)
• aarch64 (clang: __aarch64__)
• arm64ec (clang: __arm64ec__, __amd64__)

target_family="aarch64":

• aarch64 (clang: __aarch64__)
• arm64ec (clang: __arm64ec__, __amd64__)

target_family="loongarch":

• loongarch32 (clang: __loongarch__, no loongarch32)
• loongarch64 (clang: __loongarch__, __loongarch64)

target_family="mips":

• mips (clang: __mips__, __mips = 32)
• mips32r6 (clang: __mips__, __mips = 32)
• mips64 (clang: __mips__, __mips64__)
• mips64r6 (clang: __mips__, __mips64__)

target_family="mips32":

• mips (clang: see above)
• mips32r6 (clang: see above)

target_family="mips64":

• mips64 (clang: see above)
• mips64r6 (clang: see above)

target_family="powerpc":

• powerpc (clang: __powerpc__, no powerpc32)
• powerpc64 (clang: __powerpc__, __powerpc64__)

target_family="riscv":

• riscv32 (clang: __riscv, no riscv32)
• riscv64 (clang: __riscv, no riscv64)

target_family="sparc":

• sparc (clang: __sparc__, no sparc32)
• sparc64 (clang: __sparc__, __sparc64__)

target_family="x86":

• x86 (clang: __i386__)
• x86_64 (clang: __x86_64__, __amd64__)

Already grouped with target_family="wasm":

• wasm32
• wasm64

Arches that get no new target_family:

• amdgpu
• avr
• bpf
• csky
• hexagon
• m68k
• msp430
• nvptx64
• s390x
• xtensa

There is a case for grouping aarch64, arm64ec, and arm under target_family="arm", but the 32- and 64-bit variants tend to be treated more independently than other 32- and 64-bit groups.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

I can mentor if needed.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.