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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

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%)

@RalfJung
Copy link
Member

I'm afraid I have no idea how to further reduce the overhead here, I don't know much about the performance characteristics of the query system. This should be a largely unchanged query and thus basically trivial to cache for incremental builds but there are many things about this I do not understand.

@compiler-errors @nnethercote maybe one of you has an idea?

@nnethercote
Copy link
Contributor

The detailed results for cargo debug incr-unchanged show that the incr_comp_encode_dep_graph query is being called a lot more (see the "Executions delta" column). Is that expected?

@veluca93
Copy link
Contributor Author

The detailed results for cargo debug incr-unchanged show that the incr_comp_encode_dep_graph query is being called a lot more (see the "Executions delta" column). Is that expected?

That depends on what that query does :-)
This PR adds a new query that is cached on disk and called fairly often, so probably yes.

@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 30, 2024
@bors
Copy link
Contributor

bors commented Oct 30, 2024

⌛ Trying commit 0fe5f5d with merge 81ef4c3...

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 30, 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 30, 2024

☀️ Try build successful - checks-actions
Build commit: 81ef4c3 (81ef4c3f186aa9a8fcbd05199ebb9293eac2657f)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (81ef4c3): 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)
2.3% [0.2%, 6.7%] 50
Regressions ❌
(secondary)
3.1% [0.4%, 6.2%] 10
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.2% [-0.2%, -0.2%] 1
All ❌✅ (primary) 2.3% [0.2%, 6.7%] 50

Max RSS (memory usage)

Results (primary 2.8%, secondary 2.7%)

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)
2.8% [1.4%, 5.3%] 28
Regressions ❌
(secondary)
2.7% [1.0%, 6.5%] 16
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.8% [1.4%, 5.3%] 28

Cycles

Results (primary 5.0%, secondary 6.2%)

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)
5.0% [0.9%, 11.4%] 39
Regressions ❌
(secondary)
6.2% [3.5%, 8.4%] 7
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 5.0% [0.9%, 11.4%] 39

Binary size

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

Bootstrap: 785.104s -> 786.374s (0.16%)
Artifact size: 333.62 MiB -> 333.70 MiB (0.02%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 30, 2024
@RalfJung
Copy link
Member

RalfJung commented Oct 30, 2024

Something has gone wrong somewhere -- in your earlier result, the new call_site_abi_missing_features query seems to never be called, now in the latest run it is called 8465 times.

The latest run also has a huge increase in the number of layout_of calls (262500.0%!) compared to the baseline, which didn't occur in the previous run either.

Not sure which of these two runs to trust, but at least one seems quite bogus.

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
@the8472
Copy link
Member

the8472 commented Oct 30, 2024

@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 30, 2024
@bors
Copy link
Contributor

bors commented Oct 30, 2024

⌛ Trying commit a0b7398 with merge b0fa643490dcecd6aaca72fbb8a69124265ef9ad...

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 30, 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 31, 2024

☀️ Try build successful - checks-actions
Build commit: b0fa643 (b0fa643490dcecd6aaca72fbb8a69124265ef9ad)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (b0fa643): 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.3% [0.3%, 2.8%] 48
Regressions ❌
(secondary)
1.5% [0.3%, 2.4%] 11
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.2% [-0.2%, -0.2%] 1
All ❌✅ (primary) 1.3% [0.3%, 2.8%] 48

Max RSS (memory usage)

Results (primary 2.1%, 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)
2.1% [1.1%, 4.1%] 9
Regressions ❌
(secondary)
6.2% [6.2%, 6.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.7% [-1.7%, -1.7%] 1
All ❌✅ (primary) 2.1% [1.1%, 4.1%] 9

Cycles

Results (primary 3.1%, secondary -1.4%)

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.1% [0.7%, 5.1%] 29
Regressions ❌
(secondary)
2.9% [2.5%, 3.8%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.7% [-7.9%, -2.6%] 6
All ❌✅ (primary) 3.1% [0.7%, 5.1%] 29

Binary size

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

Bootstrap: 782.919s -> 785.593s (0.34%)
Artifact size: 333.61 MiB -> 333.74 MiB (0.04%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
perf-regression Performance regression. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.