Allow optimizing u32::from::<char>.

[reitermarkus]

Extracted from #124307.

This allows optimizing the panicking branch in the escape_unicode function, see https://rust.godbolt.org/z/61YhKrhvP.

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[reitermarkus]

r? @joboet

[the8472]

You could use a transmute, it already emits the right assume in optimized builds

https://rust.godbolt.org/z/r7sqdcdzh

[joboet]

Arguably this should be done in the backend for char as u32 so that everyone can benefit from it.

[reitermarkus]

Arguably this should be done in the backend for char as u32 so that everyone can benefit from it.

Agreed, however I don't know where the code for that lives.

[clubby789]

That would be

rust/compiler/rustc_codegen_ssa/src/mir/rvalue.rs

Lines 529 to 531 in cb93c24

	(CastTy::Int(i), CastTy::Int(_)) => {
	bx.intcast(llval, ll_t_out, i.is_signed())
	}

[joboet]

I don't feel comfortable reviewing compiler changes, so
r? compiler

That said, I think this is a good idea!

[bors]

☔ The latest upstream changes (presumably #123886) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

• 526aa8c

[clubby789]

Probably best to squash the first two commits, since they add then revert the library change

[reitermarkus]

@scottmcm, I think changing the test to use ilog2 broke it. It still seems to work for each of the test functions individually, but if both are in the same file, it fails.

[scottmcm]

@reitermarkus Sorry for being slow to get back to you here. The changes are looking good and CI is passing, but based on your previous comment that's only because CI doesn't run the codegen test? What's output IR you get?

Alternatively, if you need to change x.ilog2() to 32 - x.leading_zeros() that'd be fine too. I guess it's possible the extra checks in ilog2 are confusing things a bit? (My recollection was that mostly my confusion from the former was that it was a non-trivial expression to figure out as a human why the test should do the right thing, but something simpler that's not ilog2 would also be ok.)

[scottmcm]

@reitermarkus Ping for the above?
@rustbot author

[reitermarkus]

@rustbot ready

[scottmcm]

@bors r+ rollup=never

[bors]

📌 Commit 2f2eb22 has been approved by scottmcm

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2f2eb22 with merge 3942254...

[bors]

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 3942254 to master...

[rust-timer]

Finished benchmarking commit (3942254): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.3%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.2%, 0.3%]	5

Max RSS (memory usage)

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

Cycles

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

Binary size

Results (primary 0.2%, secondary 0.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)	0.3%	[0.0%, 0.7%]	16
Regressions ❌ (secondary)	0.7%	[0.4%, 0.7%]	37
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	1
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	23
All ❌✅ (primary)	0.2%	[-0.0%, 0.7%]	17

Bootstrap: 769.985s -> 771.748s (0.23%)
Artifact size: 328.95 MiB -> 329.08 MiB (0.04%)

[pnkfelix]

Visiting for weekly rustc-perf triage

• regressions are to image opt {full, incr-full}, cargo opt {full, incr-full}, and syn opt incr-unchanged
• It appears that its due to extra time spent in LLVM opt, especially lto optimize, which makes sense given that this is meant to be enabling LLVM to attempt more such optimizations?
• marking as triaged.

@rustbot label: +perf-regression-triaged