Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit warning when calling/declaring functions with unavailable vectors. #132173

Merged
merged 1 commit into from
Nov 10, 2024

Conversation

veluca93
Copy link
Contributor

On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)

As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code.

This commit makes it a post-monomorphization future-incompat warning to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.

See the nomination comment for more discussion.

Part of #116558

r? RalfJung

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 26, 2024
@jieyouxu
Copy link
Member

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 26, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 26, 2024
Emit warning when calling/declaring functions with unavailable vectors.

On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)

As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code.

This commit makes it a post-monomorphization future-incompat warning to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.

See the [nomination comment](rust-lang#127731 (comment)) for more discussion.

Part of rust-lang#116558

r? RalfJung
@bors
Copy link
Contributor

bors commented Oct 26, 2024

⌛ Trying commit 4526613 with merge bbf9ed8...

@RalfJung
Copy link
Member

The collector always runs, so likely we'll have to make this new check a query to avoid the perf issues.

For the declaration-site check this should be fairly easy, we can pass in the monomorphized instance and that has everything we need. The call-site check is more tricky since the inputs currently are (callee_ty, *fn_span, self.body.source.instance). AFAIK we usually avoid passing a span into a query as those are quite unstable, but not sure what else to do here?
Cc @compiler-errors

@bors
Copy link
Contributor

bors commented Oct 26, 2024

☀️ Try build successful - checks-actions
Build commit: bbf9ed8 (bbf9ed8a41f053260da986cd0252b156f3866520)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (bbf9ed8): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
5.1% [0.3%, 16.8%] 75
Regressions ❌
(secondary)
4.8% [0.1%, 29.4%] 30
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 5.1% [0.3%, 16.8%] 75

Max RSS (memory usage)

Results (primary 4.2%, secondary 3.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
4.2% [1.0%, 10.1%] 68
Regressions ❌
(secondary)
3.4% [0.9%, 6.1%] 25
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.0% [-3.0%, -3.0%] 1
All ❌✅ (primary) 4.2% [1.0%, 10.1%] 68

Cycles

Results (primary 11.1%, secondary 12.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
11.1% [1.2%, 26.2%] 56
Regressions ❌
(secondary)
17.3% [2.9%, 38.6%] 9
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.6% [-4.9%, -2.9%] 3
All ❌✅ (primary) 11.1% [1.2%, 26.2%] 56

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 785.03s -> 787.479s (0.31%)
Artifact size: 333.74 MiB -> 333.57 MiB (-0.05%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Oct 26, 2024
@veluca93
Copy link
Contributor Author

@jieyouxu / @RalfJung could I get another perf run?

@rust-log-analyzer

This comment has been minimized.

@jieyouxu
Copy link
Member

You'll probably need to fix the compilation error to make it buildable, but yes

@compiler-errors
Copy link
Member

compiler-errors commented Oct 26, 2024

The call-site check is more tricky since the inputs currently are (callee_ty, *fn_span, self.body.source.instance).

@RalfJung: Why not just make the query something like (callee_ty, instance) which then returns some "status" or something that captures "should we emit a lint?" that you then use at the call-site to turn into a lint, rather than making the query responsible for emitting the lint? I agree that you almost never want to pass a span to a query.

@veluca93
Copy link
Contributor Author

The call-site check is more tricky since the inputs currently are (callee_ty, *fn_span, self.body.source.instance).

@RalfJung: Why not just make the query something like (callee_ty, instance) which then returns some "status" or something that captures "should we emit a lint?" that you then use at the call-site to turn into a lint, rather than making the query responsible for emitting the lint? I agree that you almost never want to pass a span to a query.

I thought of doing the same too - I also gave up on the previous attempt since that got in a somewhat annoying rabbit hole.
Should be ready for a perf run now!

@saethlin
Copy link
Member

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 26, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 26, 2024
Emit warning when calling/declaring functions with unavailable vectors.

On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)

As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code.

This commit makes it a post-monomorphization future-incompat warning to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.

See the [nomination comment](rust-lang#127731 (comment)) for more discussion.

Part of rust-lang#116558

r? RalfJung
@bors
Copy link
Contributor

bors commented Oct 26, 2024

⌛ Trying commit 75c873a with merge 95e2c91...

@bors
Copy link
Contributor

bors commented Oct 26, 2024

☀️ Try build successful - checks-actions
Build commit: 95e2c91 (95e2c91a1f2db67bbad2800a9838d921ab01cbbb)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (95e2c91): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
1.7% [0.2%, 3.8%] 48
Regressions ❌
(secondary)
1.9% [1.0%, 2.7%] 5
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.7% [0.2%, 3.8%] 48

Max RSS (memory usage)

Results (primary 3.1%, secondary -0.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
3.4% [1.4%, 6.5%] 21
Regressions ❌
(secondary)
4.4% [4.4%, 4.4%] 1
Improvements ✅
(primary)
-1.8% [-1.8%, -1.8%] 1
Improvements ✅
(secondary)
-1.6% [-4.0%, -0.4%] 6
All ❌✅ (primary) 3.1% [-1.8%, 6.5%] 22

Cycles

Results (primary 3.2%, secondary 3.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
3.2% [1.6%, 6.3%] 29
Regressions ❌
(secondary)
3.0% [3.0%, 3.1%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.2% [1.6%, 6.3%] 29

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 783.187s -> 786.602s (0.44%)
Artifact size: 333.73 MiB -> 333.78 MiB (0.02%)

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 9, 2024
@matthiaskrgr
Copy link
Member

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 9, 2024
@bors
Copy link
Contributor

bors commented Nov 10, 2024

⌛ Testing commit c8b76bc with merge 7660aed...

@bors
Copy link
Contributor

bors commented Nov 10, 2024

☀️ Test successful - checks-actions
Approved by: RalfJung,compiler-errors
Pushing 7660aed to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 10, 2024
@bors bors merged commit 7660aed into rust-lang:master Nov 10, 2024
7 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Nov 10, 2024
@bors bors mentioned this pull request Nov 10, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7660aed): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
0.5% [0.2%, 1.0%] 36
Regressions ❌
(secondary)
0.6% [0.2%, 0.9%] 6
Improvements ✅
(primary)
-0.4% [-0.4%, -0.4%] 1
Improvements ✅
(secondary)
-0.1% [-0.1%, -0.1%] 1
All ❌✅ (primary) 0.5% [-0.4%, 1.0%] 37

Max RSS (memory usage)

Results (primary 3.2%, secondary 0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
3.8% [0.8%, 11.6%] 8
Regressions ❌
(secondary)
4.1% [2.6%, 6.1%] 3
Improvements ✅
(primary)
-1.8% [-1.8%, -1.8%] 1
Improvements ✅
(secondary)
-3.4% [-4.6%, -1.3%] 3
All ❌✅ (primary) 3.2% [-1.8%, 11.6%] 9

Cycles

Results (primary 1.2%, secondary 2.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
1.2% [0.6%, 1.9%] 8
Regressions ❌
(secondary)
2.3% [1.7%, 3.0%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.2% [0.6%, 1.9%] 8

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 780.152s -> 784.572s (0.57%)
Artifact size: 335.33 MiB -> 335.21 MiB (-0.03%)

@RalfJung
Copy link
Member

That's about as expected -- it's the best we managed after a whole bunch of experimentation: one fully cached extra query per monomorphized function.

@Mark-Simulacrum Mark-Simulacrum added the perf-regression-triaged The performance regression has been triaged. label Nov 11, 2024
mati865 pushed a commit to mati865/rust that referenced this pull request Nov 12, 2024
…iler-errors

Emit warning when calling/declaring functions with unavailable vectors.

On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)

As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code.

This commit makes it a post-monomorphization future-incompat warning to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.

See the [nomination comment](rust-lang#127731 (comment)) for more discussion.

Part of rust-lang#116558

r? RalfJung
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 16, 2024
…jubilee

ABI checks: add support for some tier3 arches, warn on others.

Followup to
- rust-lang#132842
- rust-lang#132173
- rust-lang#131800

r? `@workingjubilee`
jhpratt added a commit to jhpratt/rust that referenced this pull request Nov 17, 2024
…ngjubilee

ABI checks: add support for some tier3 arches, warn on others.

Followup to
- rust-lang#132842
- rust-lang#132173
- rust-lang#131800

r? `@workingjubilee`
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Nov 17, 2024
…ngjubilee

ABI checks: add support for some tier3 arches, warn on others.

Followup to
- rust-lang#132842
- rust-lang#132173
- rust-lang#131800

r? ``@workingjubilee``
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 17, 2024
Rollup merge of rust-lang#133029 - veluca93:abi-checks-tier3, r=workingjubilee

ABI checks: add support for some tier3 arches, warn on others.

Followup to
- rust-lang#132842
- rust-lang#132173
- rust-lang#131800

r? ``@workingjubilee``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 21, 2024
…er-errors,uweigand

Support s390x z13 vector ABI

cc rust-lang#130869

This resolves the following fixmes:
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/abi/call/s390x.rs#L1-L2
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9-L11

Refs: Section 1.2.3 "Parameter Passing" and section 1.2.5 "Return Values" 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)

This PR extends ~~rust-lang#127731 rust-lang#132173 (merged) 's ABI check to handle cases where `vector` target feature is disabled.
If we do not do ABI check, we run into the ABI problems as described in rust-lang#116558 and rust-lang#130869 (comment), and the problem of the compiler generating strange code (rust-lang#131586 (comment)).

cc `@uweigand`

`@rustbot` label +O-SystemZ +A-ABI
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 21, 2024
Rollup merge of rust-lang#131586 - taiki-e:s390x-vector-abi, r=compiler-errors,uweigand

Support s390x z13 vector ABI

cc rust-lang#130869

This resolves the following fixmes:
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/abi/call/s390x.rs#L1-L2
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9-L11

Refs: Section 1.2.3 "Parameter Passing" and section 1.2.5 "Return Values" 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)

This PR extends ~~rust-lang#127731 rust-lang#132173 (merged) 's ABI check to handle cases where `vector` target feature is disabled.
If we do not do ABI check, we run into the ABI problems as described in rust-lang#116558 and rust-lang#130869 (comment), and the problem of the compiler generating strange code (rust-lang#131586 (comment)).

cc `@uweigand`

`@rustbot` label +O-SystemZ +A-ABI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.