Commit Graph

120 Commits

Author SHA1 Message Date
Trevor Gross 64a3bd84d8 Always preserve user-written comments in assembly 2024-07-02 21:41:59 -04:00
Guillaume Gomez 07e8b3ac01
Rollup merge of #126555 - beetrees:f16-inline-asm-arm, r=Amanieu
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-22 12:57:18 +02:00
Jubilee e7956cd994
Rollup merge of #126530 - beetrees:f16-inline-asm-riscv, r=Amanieu
Add `f16` inline ASM support for RISC-V

This PR adds `f16` inline ASM support for RISC-V. A `FIXME` is left for `f128` support as LLVM does not support the required `Q` (Quad-Precision Floating-Point) extension yet.

Relevant issue: #125398
Tracking issue: #116909

`@rustbot` label +F-f16_and_f128
2024-06-21 21:02:26 -07:00
beetrees 771e44ebd3
Add `f16` inline ASM support for RISC-V 2024-06-21 18:48:20 +01:00
beetrees 753fb070bb
Add `f16` inline ASM support for 32-bit ARM 2024-06-21 18:26:42 +01:00
bors 1ca578e68e Auto merge of #126736 - matthiaskrgr:rollup-rb20oe3, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #126380 (Add std Xtensa targets support)
 - #126636 (Resolve Clippy `f16` and `f128` `unimplemented!`/`FIXME`s )
 - #126659 (More status-quo tests for the `#[coverage(..)]` attribute)
 - #126711 (Make Option::as_[mut_]slice const)
 - #126717 (Clean up some comments near `use` declarations)
 - #126719 (Fix assertion failure for some `Expect` diagnostics.)
 - #126730 (Add opaque type corner case test)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-20 13:36:42 +00:00
Matthias Krüger 586154b946
Rollup merge of #126380 - SergioGasquez:feat/std-xtensa, r=davidtwco
Add std Xtensa targets support

Adds std Xtensa targets. This enables using Rust on ESP32, ESP32-S2 and ESP32-S3 chips.

Tier 3 policy:

> A tier 3 target must have a designated developer or developers (the "target maintainers") on
record to be CCed when issues arise regarding the target. (The mechanism to track and CC such
developers may evolve over time.)

`@MabezDev,` `@ivmarkov` and I (`@SergioGasquez)` will maintain the targets.

> Targets must use naming consistent with any existing targets; for instance, a target for the same
CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should
normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond
Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the
name of a target can be highly disruptive, especially once the target reaches a higher tier, so
getting the name right is important even for a tier 3 target.

The target triple is consistent with other targets.

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to
maintain ecosystem compatibility. For example, if the name of the target makes people extremely
likely to form incorrect beliefs about what it targets, the name should be changed or augmented to
disambiguate it.
> If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known
to cause issues in Cargo.

We follow the same naming convention as other targets.

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or
impose onerous legal terms for the Rust project or for Rust developers or users.

The target does not introduce any legal issues.

> The target must not introduce license incompatibilities.

There are no license incompatibilities

> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Everything added is under that licenses

> The target must not cause the Rust tools or libraries built for any other host (even when
supporting cross-compilation to the target) to depend on any new dependency less permissive than the
Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding
new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether
the dependency is a native library or binary. In other words, the introduction of the target must
not cause a user installing or running a version of Rust or the Rust tools to be subject to any new
license requirements.

Requirements are not changed for any other target.

> Compiling, linking, and emitting functional binaries, libraries, or other code for the target
(whether hosted on the target itself or cross-compiling from another target) must not depend on
proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary
runtime libraries supplied by the platform and commonly used by other applications built for the
target, but those libraries must not be required for code generation for the target;
cross-compilation to the target must not require such libraries at all. For instance, rustc built
for the target may depend on a common proprietary C runtime library or console output library, but
must not depend on a proprietary code generation library or code optimization library. Rust's
license permits such combinations, but the Rust project has no interest in maintaining such
combinations within the scope of Rust itself, even at tier 3.

The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for Xtensa.
GNU GPL.

> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms
include but are not limited to: non-disclosure requirements, non-compete requirements, contributor
license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements
conditional on the employer or employment of any particular Rust developers, revocable terms, any
requirements that create liability for the Rust project or its developers or users, or any
requirements that adversely affect the livelihood or prospects of the Rust project or its developers
or users.

No such terms exist for this target

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or
estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a
target, or has any legal or employment requirement (explicit or implicit) that might affect their
decisions regarding a target, they must recuse themselves from any approval decisions regarding the
target's tier status, though they may otherwise participate in discussions.

> This requirement does not prevent part or all of this policy from being cited in an explicit
contract or work agreement (e.g. to implement or maintain support for a target). This requirement
exists to ensure that a developer or team responsible for reviewing and approving a target does not
face any legal threats or obligations that would prevent them from freely exercising their judgment
in such approval, even if such judgment involves subjective matters or goes beyond the letter of
these requirements.

Understood

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and
appropriate (core for most targets, alloc for targets that can support dynamic memory allocation,
std for targets with an operating system or equivalent layer of system-provided functionality), but
may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether
because the target makes it impossible to implement or challenging to implement. The authors of pull
requests are not obligated to avoid calling any portions of the standard library on the basis of a
tier 3 target not implementing those portions.

The targets implement libStd almost in its entirety, except for the missing support for process, as
this is a bare metal platform. The process `sys\unix` module is currently stubbed to return "not
implemented" errors.

> The target must provide documentation for the Rust community explaining how to build for the
target, using cross-compilation if possible. If the target supports running binaries, or running
tests (even if they do not pass), the documentation must explain how to run such binaries or tests
for the target, using emulation if possible or dedicated hardware if necessary.

Here is how to build for the target https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html
and it also covers how to run binaries on the target.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the
community, to maintain the target. In particular, do not post comments (automated or manual) on a PR
that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or
notifications (via any medium, including via `@)` to a PR author or others involved with a PR
regarding a tier 3 target, unless they have opted into such messages.

> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not
considered a violation of this policy, within reason. However, such messages (even on a separate
repository) must not generate notifications to anyone involved with a PR who has not requested such
notifications.

Understood

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and
must not knowingly break another tier 3 target without approval of either the compiler team or the
maintainers of the other tier 3 target.

> In particular, this may come up when working on closely related targets, such as variations of the
same architecture with different features. Avoid introducing unconditional uses of features that
another variation of the target may not have; use conditional compilation or runtime detection, as
appropriate, to let each target run code supported by that target.

No other targets should be affected

> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends
from any host target.

It can produce assembly, but it requires a custom LLVM with Xtensa support
(https://github.com/espressif/llvm-project/). The patches are trying to be upstreamed
(https://github.com/espressif/llvm-project/issues/4)
2024-06-20 14:07:01 +02:00
Gary Guo bb2716effd Fix wasm_exceptions test 2024-06-19 21:26:48 +01:00
Gary Guo 5812b1fd12 Remove c_unwind from tests and fix tests 2024-06-19 13:54:55 +01:00
bjorn3 efa213afad Add i686-unknown-redox target
Co-Authored-By: Jeremy Soller <jackpot51@gmail.com>
2024-06-16 12:56:48 +00:00
Matthias Krüger 0f2cc21547
Rollup merge of #126417 - beetrees:f16-f128-inline-asm-x86, r=Amanieu
Add `f16` and `f128` inline ASM support for `x86` and `x86-64`

This PR adds `f16` and `f128` input and output support to inline ASM on `x86` and `x86-64`. `f16` vector sizes are taken from [here](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html).

Relevant issue: #125398
Tracking issue: #116909

``@rustbot`` label +F-f16_and_f128
2024-06-15 14:40:48 +02:00
bors 7ac6c2fc68 Auto merge of #125347 - tesuji:needtests, r=nikic
Add codegen tests for E-needs-test

close #36010
close #68667
close #74938
close #83585
close #93036
close #109328
close #110797
close #111508
close #112509
close #113757
close #120440
close #118392
close #71096

r? nikic
2024-06-14 13:40:52 +00:00
beetrees dfc5514527
Add `f16` and `f128` inline ASM support for `x86` and `x86-64` 2024-06-13 16:12:23 +01:00
Sergio Gasquez 3954b744cc feat: Add std Xtensa targets support 2024-06-13 09:22:21 +02:00
bors 0285dab54f Auto merge of #125141 - SergioGasquez:feat/no_std-xtensa, r=davidtwco
Add no_std Xtensa targets support

Adds no_std Xtensa targets. This enables using Rust on ESP32, ESP32-S2 and ESP32-S3 chips.

Tier 3 policy:

> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

`@MabezDev` and I (`@SergioGasquez)` will maintain the targets.

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

The target triple is consistent with other targets.

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
> If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.

We follow the same naming convention as other targets.

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

The target does not introduce any legal issues.

> The target must not introduce license incompatibilities.

There are no license incompatibilities

> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

Everything added is under that licenses

> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.

Requirements are not changed for any other target.

> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.

The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for Xtensa. GNU GPL.

> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

No such terms exist for this target

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Understood

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

The target already implements core.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.

Here is how to build for the target https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html and it also covers how to run binaries on the target.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Understood

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

No other targets should be affected

> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

It can produce assembly, but it requires a custom LLVM with Xtensa support (https://github.com/espressif/llvm-project/). The patches are trying to be upstreamed (https://github.com/espressif/llvm-project/issues/4)
2024-06-12 13:43:31 +00:00
Jubilee 322af5c274
Rollup merge of #125980 - kjetilkjeka:nvptx_remove_direct_passmode, r=davidtwco
Nvptx remove direct passmode

This PR does what should have been done in #117671. That is fully avoid using the `PassMode::Direct` for `extern "C" fn` for `nvptx64-nvidia-cuda` and enable the compatibility test. `@RalfJung` [pointed me in the right direction](https://github.com/rust-lang/rust/issues/117480#issuecomment-2137712501) for solving this issue.

There are still some ABI bugs after this PR is merged. These ABI tests are created based on what is actually correct, and since they continue passing with even more of them enabled things are improving. I don't have the time to tackle all the remaining issues right now, but I think getting these improvements merged is very valuable in themselves and plan to tackle more of them long term.

This also doesn't remove the use of `PassMode::Direct` for `extern "ptx-kernel" fn`. This was also not trivial to make work. And since the ABI is hidden behind an unstable feature it's less urgent.

I don't know if it's correct to request `@RalfJung` as a reviewer (due to team structures), but he helped me a lot to figure out this stuff. If that's not appropriate then `@davidtwco` would be a good candidate since he know about this topic from #117671

r​? `@RalfJung`
2024-06-12 03:57:20 -07:00
Lzu Tao ab0f87ec66 Fix tests for 32 bits targets 2024-06-11 07:45:16 +00:00
Lzu Tao f9edd864df Apply suggestions from code review
Co-authored-by: Nikita Popov <github@npopov.com>
2024-06-09 13:25:12 +00:00
Lzu Tao 2120ea5a91 add assembly test for #83585 2024-06-09 07:35:24 +00:00
Jubilee Young fb6fbf02a6 Use FileCheck to parameterize codegen tests over hashes
When things like our internal hashing or representations change,
it is inappropriate for these tests to suddenly fail for no reason.
The chance of error is reduced if we instead pattern-match.
2024-06-04 01:30:51 -07:00
Kjetil Kjeka a49fe0a58c NVPTX:_Especially add the DoubleI32 struct as a nvptx abi test case since it was used as an example when discussing possible problems 2024-05-31 23:12:33 +02:00
Kjetil Kjeka 14348d9519 NVPTX: Avoid PassMode::Direct for C ABI 2024-05-31 22:45:27 +02:00
Nicholas Nethercote d063c7b6c8 Run rustfmt on `tests/assembly/`. 2024-05-30 16:15:46 +10:00
Sergio Gasquez 11f70d78f5 Add no_std Xtensa targets support 2024-05-29 13:48:11 +01:00
许杰友 Jieyou Xu (Joe) 3cc59aeaae
Rollup merge of #125226 - madsmtm:fix-mac-catalyst-tests, r=workingjubilee
Make more of the test suite run on Mac Catalyst

Combined with https://github.com/rust-lang/rust/pull/125225, the only failing parts of the test suite are in `tests/rustdoc-js`, `tests/rustdoc-js-std` and `tests/debuginfo`. Tested with:
```console
./x test --target=aarch64-apple-ios-macabi library/std
./x test --target=aarch64-apple-ios-macabi --skip=tests/rustdoc-js --skip=tests/rustdoc-js-std --skip=tests/debuginfo tests
```

Will probably put up a PR later to enable _running_ on (not just compiling for) Mac Catalyst in CI, though not sure where exactly I should do so? `src/ci/github-actions/jobs.yml`?

Note that I've deliberately _not_ enabled stack overflow handlers on iOS/tvOS/watchOS/visionOS (see https://github.com/rust-lang/rust/issues/25872), but rather just skipped those tests, as it uses quite a few APIs that I'd be weary about getting rejected by the App Store (note that Swift doesn't do it on those platforms either).

r? ``@workingjubilee``

CC ``@thomcc``

``@rustbot`` label O-ios O-apple
2024-05-29 03:25:08 +01:00
Matthias Krüger 713c852a2f
Rollup merge of #117671 - kjetilkjeka:nvptx_c_abi_avoid_direct, r=davidtwco
NVPTX: Avoid PassMode::Direct for args in C abi

Fixes #117480

I must admit that I'm confused about `PassMode` altogether, is there a good sum-up threads for this anywhere? I'm especially confused about how "indirect" and "byval" goes together. To me it seems like "indirect" basically means "use a indirection through a pointer", while "byval" basically means "do not use indirection through a pointer".

The return used to keep `PassMode::Direct` for small aggregates. It turns out that `make_indirect` messes up the tests and one way to fix it is to keep `PassMode::Direct` for all aggregates. I have mostly seen this PassMode mentioned for args. Is it also a problem for returns? When experimenting with `byval` as an alternative i ran into [this assert](61a3eea804/compiler/rustc_codegen_llvm/src/abi.rs (L463C22-L463C22))

I have added tests for the same kind of types that is already tested for the "ptx-kernel" abi. The tests cannot be enabled until something like #117458 is completed and merged.

CC: ``@RalfJung`` since you seem to be the expert on this and have already helped me out tremendously

CC: ``@RDambrosio016`` in case this influence your work on `rustc_codegen_nvvm`

``@rustbot`` label +O-NVPTX
2024-05-28 18:04:31 +02:00
Mads Marquart e6b9bb7b72 Make more of the test suite run on Mac Catalyst
This adds the `only-apple`/`ignore-apple` compiletest directive, and
uses that basically everywhere instead of `only-macos`/`ignore-macos`.

Some of the updates in `run-make` are a bit redundant, as they use
`ignore-cross-compile` and won't run on iOS - but using Apple in these
is still more correct, so I've made that change anyhow.
2024-05-28 12:31:33 +02:00
Federico Maria Morrone 923cdb35aa
test: Add assembly tests for x86_64-unknown-linux-none target 2024-05-12 01:25:11 +02:00
Kjetil Kjeka ead02ba0f1 NVPTX: Avoid PassMode::Direct for args in C abi 2024-05-10 18:39:05 +02:00
Josh Stone 1b79bb937f Add inline comments why we're forcing the target cpu 2024-05-01 16:54:20 -07:00
Josh Stone 706f06c39a Use an explicit x86-64 cpu in tests that are sensitive to it
There are a few tests that depend on some target features **not** being
enabled by default, and usually they are correct with the default x86-64
target CPU. However, in downstream builds we have modified the default
to fit our distros -- `x86-64-v2` in RHEL 9 and `x86-64-v3` in RHEL 10
-- and the latter especially trips tests that expect not to have AVX.

These cases are few enough that we can just set them back explicitly.
2024-05-01 15:25:26 -07:00
许杰友 Jieyou Xu (Joe) 4b6c1918ee
Rollup merge of #124299 - clubby789:106269-test, r=nikic
Add test for issue 106269

Closes #106269

Made this an assembly test as the LLVM codegen is still quite verbose and doesn't really indicate the behaviour we want
2024-04-30 19:29:51 +01:00
clubby789 7032c92b33 Add test for efficient codegen of manual `eq` implementations of a small struct 2024-04-30 13:21:08 +00:00
Erik Desjardins 6df27ef88f also update windows slack-protector tests 2024-04-22 23:45:04 -04:00
Erik Desjardins d46b688945 adjust stack-protector test (which inappropriately depends on IR types) 2024-04-11 21:42:35 -04:00
Daniel Paoliello 2e44d29460 Add support for Arm64EC inline assembly 2024-04-10 10:06:44 -07:00
Guillaume Gomez 74a5bc6c9e
Rollup merge of #121419 - agg23:xrOS-pr, r=davidtwco
Add aarch64-apple-visionos and aarch64-apple-visionos-sim tier 3 targets

Introduces `aarch64-apple-visionos` and `aarch64-apple-visionos-sim` as tier 3 targets. This allows native development for the Apple Vision Pro's visionOS platform.

This work has been tracked in https://github.com/rust-lang/compiler-team/issues/642. There is a corresponding `libc` change https://github.com/rust-lang/libc/pull/3568 that is not required for merge.

Ideally we would be able to incorporate [this change](https://github.com/gimli-rs/object/pull/626) to the `object` crate, but the author has stated that a release will not be cut for quite a while. Therefore, the two locations that would reference the xrOS constant from `object` are hardcoded to their MachO values of 11 and 12, accompanied by TODOs to mark the code as needing change. I am open to suggestions on what to do here to get this checked in.

# Tier 3 Target Policy

At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

See [src/doc/rustc/src/platform-support/apple-visionos.md](e88379034a/src/doc/rustc/src/platform-support/apple-visionos.md)

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
> * Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
> * If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.

This naming scheme matches `$ARCH-$VENDOR-$OS-$ABI` which is matches the iOS Apple Silicon simulator (`aarch64-apple-ios-sim`) and other Apple targets.

> Tier 3 targets may have unusual requirements to build or use, but must not
  create legal issues or impose onerous legal terms for the Rust project or for
  Rust developers or users.
>  - The target must not introduce license incompatibilities.
>  - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`).
>  - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to besubject to any new license requirements.
>  - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, `rustc` built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are *not* limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

This contribution is fully available under the standard Rust license with no additional legal restrictions whatsoever. This PR does not introduce any new dependency less permissive than the Rust license policy.

The new targets do not depend on proprietary libraries.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

This new target mirrors the standard library for watchOS and iOS, with minor divergences.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.

Documentation is provided in [src/doc/rustc/src/platform-support/apple-visionos.md](e88379034a/src/doc/rustc/src/platform-support/apple-visionos.md)

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> * This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> * Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> * In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

I acknowledge these requirements and intend to ensure that they are met.

This target does not touch any existing tier 2 or tier 1 targets and should not break any other targets.
2024-04-05 22:33:25 +02:00
bors a77322c16f Auto merge of #118310 - scottmcm:three-way-compare, r=davidtwco
Add `Ord::cmp` for primitives as a `BinOp` in MIR

Update: most of this OP was written months ago.  See https://github.com/rust-lang/rust/pull/118310#issuecomment-2016940014 below for where we got to recently that made it ready for review.

---

There are dozens of reasonable ways to implement `Ord::cmp` for integers using comparison, bit-ops, and branches.  Those differences are irrelevant at the rust level, however, so we can make things better by adding `BinOp::Cmp` at the MIR level:

1. Exactly how to implement it is left up to the backends, so LLVM can use whatever pattern its optimizer best recognizes and cranelift can use whichever pattern codegens the fastest.
2. By not inlining those details for every use of `cmp`, we drastically reduce the amount of MIR generated for `derive`d `PartialOrd`, while also making it more amenable to MIR-level optimizations.

Having extremely careful `if` ordering to μoptimize resource usage on broadwell (#63767) is great, but it really feels to me like libcore is the wrong place to put that logic.  Similarly, using subtraction [tricks](https://graphics.stanford.edu/~seander/bithacks.html#CopyIntegerSign) (#105840) is arguably even nicer, but depends on the optimizer understanding it (https://github.com/llvm/llvm-project/issues/73417) to be practical.  Or maybe [bitor is better than add](https://discourse.llvm.org/t/representing-in-ir/67369/2?u=scottmcm)?  But maybe only on a future version that [has `or disjoint` support](https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036?u=scottmcm)?  And just because one of those forms happens to be good for LLVM, there's no guarantee that it'd be the same form that GCC or Cranelift would rather see -- especially given their very different optimizers.  Not to mention that if LLVM gets a spaceship intrinsic -- [which it should](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Suboptimal.20inlining.20in.20std.20function.20.60binary_search.60/near/404250586) -- we'll need at least a rustc intrinsic to be able to call it.

As for simplifying it in Rust, we now regularly inline `{integer}::partial_cmp`, but it's quite a large amount of IR.  The best way to see that is with 8811efa88b (diff-d134c32d028fbe2bf835fef2df9aca9d13332dd82284ff21ee7ebf717bfa4765R113) -- I added a new pre-codegen MIR test for a simple 3-tuple struct, and this PR change it from 36 locals and 26 basic blocks down to 24 locals and 8 basic blocks.  Even better, as soon as the construct-`Some`-then-match-it-in-same-BB noise is cleaned up, this'll expose the `Cmp == 0` branches clearly in MIR, so that an InstCombine (#105808) can simplify that to just a `BinOp::Eq` and thus fix some of our generated code perf issues.  (Tracking that through today's `if a < b { Less } else if a == b { Equal } else { Greater }` would be *much* harder.)

---

r? `@ghost`
But first I should check that perf is ok with this
~~...and my true nemesis, tidy.~~
2024-04-02 19:21:44 +00:00
Aria Beingessner ea92faec49 stabilize ptr.is_aligned, move ptr.is_aligned_to to a new feature gate
This is an alternative to #121920
2024-03-29 19:59:46 -04:00
Scott McMurray 3da115a93b Add+Use `mir::BinOp::Cmp` 2024-03-23 23:23:41 -07:00
bors d6eb0f5a09 Auto merge of #122582 - scottmcm:swap-intrinsic-v2, r=oli-obk
Let codegen decide when to `mem::swap` with immediates

Making `libcore` decide this is silly; the backend has so much better information about when it's a good idea.

Thus this PR introduces a new `typed_swap` intrinsic with a fallback body, and replaces that fallback implementation when swapping immediates or scalar pairs.

r? oli-obk

Replaces #111744, and means we'll never need more libs PRs like #111803 or #107140
2024-03-23 13:57:55 +00:00
Scott McMurray 75d2e5b123 Avoid non-windows non-linux in assembly x64 test 2024-03-23 00:02:53 -07:00
bors cdb683f6e4 Auto merge of #122024 - clubby789:remove-spec-option-pe, r=jhpratt
Remove SpecOptionPartialEq

With the recent LLVM bump, the specialization for Option::partial_eq on types with niches is no longer necessary. I kept the manual implementation as it still gives us better codegen than the derive (will look at this seperately).

Also implemented PartialOrd/Ord by hand as it _somewhat_ improves codegen for #49892: https://godbolt.org/z/vx5Y6oW4Y
2024-03-22 04:06:25 +00:00
Roy Buitenhuis 2fca27cd3b Add bare metal riscv32 target. 2024-03-20 16:02:10 +01:00
clubby789 5f254d8b66 Remove `SpecOptionPartialEq` 2024-03-19 16:32:01 +00:00
Adam Gastineau 11ea14e9b9 Update visionOS MachO tests to require LLVM 18 2024-03-18 20:51:37 -07:00
Adam Gastineau 4f6f433745 Support for visionOS 2024-03-18 20:45:45 -07:00
Scott McMurray 7d537106a1 Let codegen decide when to `mem::swap` with immediates
Making `libcore` decide this is silly; the backend has so much better information about when it's a good idea.

So introduce a new `typed_swap` intrinsic with a fallback body, but replace that implementation for immediates and scalar pairs.
2024-03-17 11:59:18 -07:00
Jubilee 947d960243
Rollup merge of #121953 - jhorstmann:assembly-tests-for-masked-simd-instructions, r=workingjubilee
Add tests for the generated assembly of mask related simd instructions.

The tests show that the code generation currently uses the least significant bits of <iX x N> vector masks when converting to <i1 xN>. This leads to an additional left shift operation in the assembly for x86, since mask operations on x86 operate based on the most significant bit.

The exception is simd_bitmask, which already uses the most-significant bit.

This additional instruction would be removed by the changes in #104693, which makes all mask operations consistently use the most significant bits.

By using the "C" calling convention the tests should be stable regarding changes in register allocation, but it is possible that future llvm updates will require updating some of the checks.
2024-03-12 09:03:59 -07:00
bors 5b7343b966 Auto merge of #122170 - alexcrichton:rename-wasi-threads, r=petrochenkov
Rename `wasm32-wasi-preview1-threads` to `wasm32-wasip1-threads`

This commit renames the current `wasm32-wasi-preview1-threads` target to `wasm32-wasip1-threads`. The need for this rename is a bit unfortunate as the previous name was chosen in an attempt to be future-compatible with other WASI targets. Originally this target was proposed to be `wasm32-wasi-threads`, and that's what was originally implemented in wasi-sdk as well. After discussion though and with the plans for the upcoming component-model target (now named `wasm32-wasip2`) the "preview1" naming was chosen for the threads-based target. The WASI subgroup later decided that it was time to drop the "preview" terminology and recommends "pX" instead, hence previous PRs to add `wasm32-wasip2` and rename `wasm32-wasi` to `wasm32-wasip1`.

So, with all that history, the "proper name" for this target is different than its current name, so one way or another a rename is required. This PR proposes renaming this target cold-turkey, unlike `wasm32-wasi` which is having a long transition period to change its name. The threads-based target is predicted to see only a fraction of the traffic of `wasm32-wasi` due to the unstable nature of the WASI threads proposal itself.

While I was here I updated the in-tree documentation in the target spec file itself as most of the documentation was copied from the original WASI target and wasn't as applicable to this target.

Also, as an aside, I can at least try to apologize for all the naming confusion here, but this is hopefully the last WASI-related rename.
2024-03-12 08:30:46 +00:00