Don't ICE in might_permit_raw_init if reference is polymorphic

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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

[compiler-errors]

Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.

cc @saethlin
fixes#107999

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oh, lol, this is totally wrong. this is might_permit_raw_init_lax, not known_to_permit_raw_init_lax (or something worded like that) :/ this probably should return true in that case...

@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.

[saethlin]

Not sure what you're asking, but I'll guess.

If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T has alignment > 1, in which case the 0x1-filling is invalid.

If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.

[compiler-errors]

What I'm saying is that it's probably not correct to return either false (like I did) or true (like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.

CI failure(edited link) shows that false is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.

^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions

Second PR in this stack makes the queries you added fallible, so we can handle the LayoutErrors gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.

[saethlin]

and true is also probably not great, since we're dropping this assertion

If this function is not allowed to have false positives maybe it shouldn't be called might_

[RalfJung]

The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.

We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler.

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types.

[compiler-errors]

But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries

I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with

@bors try @rust-timer queue

[bors]

⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475...

[bors]

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

[rust-timer]

Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Improvements ✅ (primary)	-3.5%	[-3.5%, -3.5%]	1
Improvements ✅ (secondary)	-2.1%	[-2.9%, -0.9%]	15
All ❌✅ (primary)	-3.5%	[-3.5%, -3.5%]	1

Cycles

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

[oli-obk]

@bors r+

[bors]

📌 Commit b096f0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

Spurious it seems

@bors retry

[bors]

⌛ Testing commit b096f0e with merge c528357...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c528357 to master...

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:00

[rust-timer]

Finished benchmarking commit (c528357): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	4.8%	[3.9%, 5.6%]	2
Improvements ✅ (primary)	-3.3%	[-3.4%, -3.2%]	2
Improvements ✅ (secondary)	-2.4%	[-4.8%, -0.6%]	50
All ❌✅ (primary)	-3.3%	[-3.4%, -3.2%]	2

Cycles

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