summary refs log tree commit diff
path: root/compiler/rustc_target/src/asm
AgeCommit message (Collapse)AuthorLines
2024-11-07Auto merge of #132472 - taiki-e:sparc-asm, r=Amanieubors-0/+168
Basic inline assembly support for SPARC and SPARC64 This implements asm_experimental_arch (tracking issue https://github.com/rust-lang/rust/issues/93335) for SPARC and SPARC64. This PR includes: - General-purpose registers `r[0-31]` (`reg` register class, LLVM/GCC constraint `r`) Supported types: i8, i16, i32, i64 (SPARC64-only) Aliases: `g[0-7]` (`r[0-7]`), `o[0-7]` (`r[8-15]`), `l[0-7]` (`r[16-23]`), `i[0-7]` (`r[24-31]`) - `y` register (clobber-only, needed for clobber_abi) - preserves_flags: Integer condition codes (`icc`, `xcc`) and floating-point condition codes (`fcc*`) The following are *not* included: - 64-bit integer support on SPARC-V8+'s global or out registers (`g[0-7]`, `o[0-7]`): GCC's `h` constraint (it seems that there is no corresponding constraint in LLVM?) - Floating-point registers (LLVM/GCC constraint `e`/`f`): I initially tried to implement this, but postponed it for now because there seemed to be several parts in LLVM that behaved differently than in the LangRef's description. - clobber_abi: Support for floating-point registers is needed. Refs: - LLVM - Reserved registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L52 - Register definitions https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.td - Supported constraints https://llvm.org/docs/LangRef.html#supported-constraint-code-list - GCC - Reserved registers https://github.com/gcc-mirror/gcc/blob/63b6967b06b5387821c4e5f2c113da6aaeeae2b7/gcc/config/sparc/sparc.h#L633-L658 - Supported constraints https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html - SPARC ISA/ABI - (64-bit ISA) The SPARC Architecture Manual, Version 9 (32-bit ISA) The SPARC Architecture Manual, Version 8 (64-bit ABI) System V Application Binary Interface SPARC Version 9 Processor Supplement, Rev 1.35 (32-bit ABI) System V Application Binary Interface SPARC Processor Supplement, Third Edition The above docs can be downloaded from https://sparc.org/technical-documents - (32-bit V8+ ABI) The V8+ Technical Specification https://temlib.org/pub/SparcStation/Standards/V8plus.pdf cc `@thejpster` (sparc-unknown-none-elf target maintainer) (AFAIK, other sparc/sprac64 targets don't have target maintainers) r? `@Amanieu` `@rustbot` label +O-SPARC +A-inline-assembly
2024-11-07Add links about clobber_abi on PowerPCTaiki Endo-0/+15
2024-11-07Remove fixme comment about clobber_abi on PowerPCTaiki Endo-2/+0
2024-11-07Basic inline assembly support for SPARC and SPARC64Taiki Endo-0/+168
2024-11-02Support clobber_abi and vector registers (clobber-only) in PowerPC inline ↵Taiki Endo-3/+105
assembly
2024-10-14Rollup merge of #131667 - taiki-e:aarch64-inline-asm-reg-emit, r=AmanieuMatthias Krüger-3/+57
Fix AArch64InlineAsmReg::emit Currently, this method uses `self as u32 - Self::x0 as u32` to get register index: https://github.com/rust-lang/rust/blob/36780360b62320a61e2234b17ec600e8e4785509/compiler/rustc_target/src/asm/aarch64.rs#L204 However, this is incorrect for reasons explained in the following comment: https://github.com/rust-lang/rust/blob/36780360b62320a61e2234b17ec600e8e4785509/compiler/rustc_codegen_llvm/src/asm.rs#L544-L549 r? ``@Amanieu`` ``@rustbot`` label O-AArch64 +A-inline-assembly
2024-10-14Fix AArch64InlineAsmReg::emitTaiki Endo-3/+57
2024-10-14Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assemblyTaiki Endo-20/+34
2024-10-06Support clobber_abi in MSP430 inline assemblyTaiki Endo-0/+10
2024-10-01Rollup merge of #130630 - taiki-e:s390x-clobber-abi, r=AmanieuGuillaume Gomez-12/+128
Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (https://github.com/rust-lang/rust/pull/111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121 - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121 - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (https://github.com/rust-lang/rust/pull/119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (https://github.com/rust-lang/rustc_codegen_gcc/issues/485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in https://github.com/rust-lang/rust/pull/127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... https://github.com/rust-lang/rust/pull/88245#issuecomment-905559591 cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-2/+2
2024-09-21Support clobber_abi and vector/access registers (clobber-only) in s390x ↵Taiki Endo-12/+128
inline assembly
2024-09-03Add `warn(unreachable_pub)` to `rustc_target`.Nicholas Nethercote-1/+1
2024-08-25Add `f16` and `f128` inline ASM support for `aarch64`beetrees-3/+3
2024-08-24Enable f16 in assembly on aarch64 platforms that support itrongfu.leng-3/+3
Signed-off-by: rongfu.leng <lenronfu@gmail.com>
2024-07-29Reformat `use` declarations.Nicholas Nethercote-39/+72
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-06-22compiler: Fix arm32 asm issues by hierarchically sorting reg classesJubilee Young-40/+40
2024-06-22Rollup merge of #126555 - beetrees:f16-inline-asm-arm, r=AmanieuGuillaume Gomez-5/+7
Add `f16` inline ASM support for 32-bit ARM Adds `f16` inline ASM support for 32-bit ARM. SIMD vector types are taken from [here](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A32]).` Relevant issue: #125398 Tracking issue: #116909 `@rustbot` label +F-f16_and_f128
2024-06-21Add `f16` inline ASM support for RISC-Vbeetrees-3/+4
2024-06-21Add `f16` inline ASM support for 32-bit ARMbeetrees-5/+7
2024-06-13Add `f16` and `f128` inline ASM support for `x86` and `x86-64`beetrees-11/+23
2024-04-29Remove `extern crate rustc_macros` from numerous crates.Nicholas Nethercote-20/+3
2024-04-11Rollup merge of #123740 - veera-sivarajan:reduce-size-of-modifierinfo, ↵Matthias Krüger-3/+3
r=petrochenkov Reduce Size of `ModifierInfo` I added `ModifierInfo` in #121940 and had used a `u64` for the `size` field even though the largest value it holds is `512`. This PR changes the type of the `size` field to `u16`.
2024-04-10Reduce size of `ModifierInfo`Veera-3/+3
2024-04-10Add support for Arm64EC inline assemblyDaniel Paoliello-24/+48
2024-03-13Improve styleVeera-2/+2
2024-03-03Mention Register Size in `#[warn(asm_sub_register)]`Veera-85/+85
Fixes #121593
2024-01-03Support reg_addr register class in s390x inline assemblyTaiki Endo-14/+15
2023-10-21update the registers of cskydirreke-3/+3
2023-08-14add details for csky-unknown-linux-gnuabiv2 and add docsDirreke-31/+17
2023-08-14add a csky-unknown-linux-gnuabiv2 targetDirreke-0/+166
2023-07-18support for mips32r6 as a target_arch valuechenx97-1/+1
2023-07-18merge patternschenx97-2/+1
2023-07-18support for mips64r6 as a target_arch valuechenx97-0/+1
2023-05-12asm: loongarch64: Drop efiapiWANG Rui-2/+2
2023-05-08Simplify match statement since variable arch that is predictableWANG Rui-5/+4
2023-05-05asm: loongarch64: Implementation of clobber_abiWANG Rui-0/+20
2023-04-25Add loongarch64 asm! supportzhaixiaojuan-0/+157
2023-04-12Add inline assembly support for m68kIan Douglas Scott-0/+105
2023-03-01Use FxIndexSet instead of FxHashSet for asm_target_features query.Michael Woerister-25/+26
2023-01-14Fix some missed double spaces.André Vennberg-1/+1
2023-01-05Fix `uninlined_format_args` for some compiler cratesnils-24/+24
Convert all the crates that have had their diagnostic migration completed (except save_analysis because that will be deleted soon and apfloat because of the licensing problem).
2022-07-20Remove unused StableMap and StableSet types from rustc_data_structuresMichael Woerister-4/+4
2022-07-08Collapse some weirdly-wrapping derivesMichael Goulet-48/+8
2022-06-18rustc_target: Remove some redundant target propertiesVadim Petrochenkov-1/+1
2022-05-17Add ABI clobbersConnor Horman-0/+2
2022-05-16Add tmm_reg clobbersConnor Horman-0/+13
2022-04-25Remove references to git.ioEric Huss-1/+2
2022-04-19asm: Add a kreg0 register class on x86 which includes k0Amanieu d'Antras-8/+9
Previously we only exposed a kreg register class which excludes the k0 register since it can't be used in many instructions. However k0 is a valid register and we need to have a way of marking it as clobbered for clobber_abi. Fixes #94977
2022-03-22Fold aarch64 feature +fp into +neonJubilee Young-1/+1
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64: The Neon unit, which handles both floating point and SIMD instructions. Moreover, a configuration for AArch64 must include both or neither. Arm says "entirely proprietary" toolchains may omit floating point: https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point In the Programmer's Guide for Armv8-A, Arm says AArch64 can have both FP and Neon or neither in custom implementations: https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON In "Bare metal boot code for Armv8-A", enabling Neon and FP is just disabling the same trap flag: https://developer.arm.com/documentation/dai0527/a In an unlikely future where "Neon and FP" become unrelated, we can add "[+-]fp" as its own feature flag. Until then, we can simplify programming with Rust on AArch64 by folding both into "[+-]neon", which is valid as it supersets both. "[+-]neon" is retained for niche uses such as firmware, kernels, "I just hate floats", and so on.