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

veluca93 · 2024-10-26T07:37:46Z

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

jieyouxu · 2024-10-26T09:01:21Z

@bors try @rust-timer queue

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 · 2024-10-26T09:02:33Z

⌛ Trying commit 4526613 with merge bbf9ed8...

RalfJung · 2024-10-26T09:13:36Z

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 · 2024-10-26T10:56:30Z

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

rust-timer · 2024-10-26T12:14:13Z

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

veluca93 · 2024-10-26T14:18:26Z

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

jieyouxu · 2024-10-26T14:28:47Z

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

compiler-errors · 2024-10-26T16:27:15Z

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 · 2024-10-26T16:54:34Z

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 · 2024-10-26T20:03:48Z

@bors try @rust-timer queue

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 · 2024-10-26T20:05:00Z

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

bors · 2024-10-26T21:56:16Z

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

rust-timer · 2024-10-27T00:16:15Z

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 · 2024-11-01T15:40:05Z

@bors try
@rust-timer queue

bors · 2024-11-01T15:41:24Z

⌛ Trying commit d47415f with merge d839ca1...

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 · 2024-11-01T17:36:39Z

☀️ Try build successful - checks-actions
Build commit: d839ca1 (d839ca1302982e1abc22f2df09950875983259d1)

compiler/rustc_middle/src/query/keys.rs

compiler/rustc_middle/src/query/mod.rs

compiler/rustc_monomorphize/src/collector/abi_check.rs

RalfJung · 2024-11-01T17:53:16Z

compiler/rustc_monomorphize/src/collector/abi_check.rs

Since this entire file is now only invoked via a query, it can be moved to a different crate.

However, I can't really think of where it should go... rustc_target doesn't have enough dependencies. So we can also keep it here for now 🤷

perf experiment: disable large-move-check This is to figure out whether it's worth moving this check into a query, like we are doing for another mono-time check in rust-lang#132173.

rust-timer · 2024-11-01T18:53:05Z

Finished benchmarking commit (d839ca1): 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)	0.5%	[0.2%, 0.9%]	35
Regressions ❌ (secondary)	0.7%	[0.5%, 0.8%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.2%, 0.9%]	35

Max RSS (memory usage)

Results (primary 1.4%, secondary 0.9%)

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.4%	[0.6%, 2.4%]	5
Regressions ❌ (secondary)	6.0%	[6.0%, 6.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.8%	[-0.8%, -0.8%]	3
All ❌✅ (primary)	1.4%	[0.6%, 2.4%]	5

Cycles

Results (secondary 2.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)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.3%, 3.7%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 779.851s -> 782.614s (0.35%)
Artifact size: 334.92 MiB -> 334.87 MiB (-0.02%)

RalfJung · 2024-11-01T19:29:15Z

Best results yet. :)

Curiously, the new query doesn't even show up in the detailed results (sorted by "executions delta"). Only incr_comp_encode_dep_graph does.

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

veluca93 · 2024-11-01T21:25:48Z

Best results yet. :)

Curiously, the new query doesn't even show up in the detailed results (sorted by "executions delta"). Only incr_comp_encode_dep_graph does.

That makes sense, in incr-unchanged build the new query should not run at all, no?

I uploaded a cleaned up version without early exit, I assume we should double check performance did not reduce significantly :-)

RalfJung · 2024-11-02T08:28:00Z

Yes, indeed.
@bors try
@rust-timer queue

This LGTM from my side, but I don't have much experience with queries, so would be good if maybe @compiler-errors or @cjgillot could take a look at that.

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 · 2024-11-02T08:29:11Z

⌛ Trying commit c8b76bc with merge f348d29...

bors · 2024-11-02T10:18:07Z

☀️ Try build successful - checks-actions
Build commit: f348d29 (f348d295daaaf2fc62ab842ae33f817d233c6812)

rust-timer · 2024-11-02T12:59:24Z

Finished benchmarking commit (f348d29): 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)	0.5%	[0.2%, 1.0%]	35
Regressions ❌ (secondary)	0.8%	[0.6%, 0.9%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.2%, 1.0%]	35

Max RSS (memory usage)

Results (primary 1.9%, secondary 1.9%)

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.7%	[0.9%, 4.2%]	12
Regressions ❌ (secondary)	5.8%	[5.4%, 6.2%]	2
Improvements ✅ (primary)	-2.4%	[-3.7%, -1.2%]	2
Improvements ✅ (secondary)	-0.8%	[-0.8%, -0.8%]	3
All ❌✅ (primary)	1.9%	[-3.7%, 4.2%]	14

Cycles

Results (primary 1.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)	1.0%	[0.9%, 1.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.9%, 1.2%]	2

Binary size

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

Bootstrap: 779.165s -> 783.303s (0.53%)
Artifact size: 335.32 MiB -> 335.30 MiB (-0.01%)

RalfJung · 2024-11-02T14:49:55Z

That seems about the same.

RalfJung · 2024-11-05T19:56:41Z

This LGTM from my side, but I don't have much experience with queries,

r? @compiler-errors

rustbot assigned RalfJung Oct 26, 2024

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