Replacement of #114390: Add new intrinsic is_var_statically_known and optimize pow for powers of two

[NCGThompson]

This adds a new intrinsic is_val_statically_known that lowers to @llvm.is.constant.*. It also applies the intrinsic in the int_pow methods to recognize and optimize the idiom 2isize.pow(x). See #114390 for more discussion.

While I have extended the scope of the power of two optimization from #114390, I haven't added any new uses for the intrinsic. That can be done in later pull requests.

Note: When testing or using the library, be sure to use --stage 1 or higher. Otherwise, the intrinsic will be a noop and the doctests will be skipped. If you are trying out edits, you may be interested in --keep-stage 0.

Fixes#47234
Resolves#114390
@Centri3

[rustbot]

r? @Mark-Simulacrum

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

[NCGThompson]

r? @oli-obk

[NCGThompson]

Assuming all the tests pass and no one has any suggestions, all that's left now is some changes to the function's documentation.

[NCGThompson]

@oli-obk Should I be at all concerned about GCC and Cranelift?

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[NCGThompson]

Converted back to draft so I can add support in GCC and a fallback in Cranelift.

[oli-obk]

The other backends can just return false (with a FIXME comment for the respective owners that they can address or remove as they see fit)

[NCGThompson]

The other backends can just return false (with a FIXME comment for the respective owners that they can address or remove as they see fit)

Do they have to enforce correct types? For LLVM, Centri left a FIXME note essentially saying she was only allowing a finite amount of types as inputs because she had to explicitly declare each of them. I don't have that issue with Cranelift because it isn't backed by a real intrinsic anyway. Do I have to tell Cranelift to panic when it gets an argument that LLVM can't accept?

Edit: they do not

[NCGThompson]

Force undoing that commit.

[NCGThompson]

Since I don't want to put tmi in the core docs and the intrinsic is a too unstable for formal documentation, I'll try to put info about it in this PR.

The rustc front-end (MIR passes) never attempts to resolve the intrinsic to true or false; it leaves it for the backend. The exception of course is in const contexts. LLVM will resolve the intrinsic to true when it reaches it while constant propagating. Later, LLVM does a special pass that resolves it to false unless it has a literal in the right hand side. After it determins the output during that pass, LLVM will propogate the output and eliminate any branches that become unreachable as a result. This pass even happens with -C opt-level 0. For all other optimization settings, that pass happens before general optimization is over.

[oli-obk]

codegen_gcc also still needs to handle the intrinsic

[NCGThompson]

When I next get the chance, I need to edit pow et al to better take advantage of constant propagation, then edit the codegen tests to match. After that, I will mark it as ready for review.

While saturating_mul makes the Rust more concise, it has the opposite effect on the assembly. Compile-time division works better.

[NCGThompson]

Now both codegen tests have -O. This should let it pass the test that just failed.

[oli-obk]

@bors r+ rollup=never

[bors]

📌 Commit 9dccd5d has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9dccd5d with merge 039d887...

[bors]

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

[rust-timer]

Finished benchmarking commit (039d887): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

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

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)	9.6%	[9.6%, 9.6%]	1
Improvements ✅ (primary)	-4.5%	[-4.9%, -4.1%]	2
Improvements ✅ (secondary)	-4.5%	[-6.6%, -3.4%]	5
All ❌✅ (primary)	-4.5%	[-4.9%, -4.1%]	2

Cycles

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

Binary size

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)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.2%	[-0.2%, -0.2%]	1

Bootstrap: 662.082s -> 661.843s (-0.04%)
Artifact size: 308.26 MiB -> 308.29 MiB (0.01%)

[RalfJung]

Tests that have UB should be marked as no_run... this one is now tripping Miri, of course.

I'll file a PR.

[RalfJung]

Filed #120366

[nyurik]

@NCGThompson I tried using this new intrinsic with core::fmt::Arguments<'_>, but it crashed rustc (big report was denied because apparently compiler crashes with intrinsics are not tracked). Is it possible to solve #121001 by detecting at compile time when the Arguments is one of these cases?

 pub const fn as_str(&self) -> Option<&'static str> {
match (self.pieces, self.args) {
([], []) => Some(""),
([s], []) => Some(s),
_ => None,
}
}

[NCGThompson]

@NCGThompson I tried using this new intrinsic with core::fmt::Arguments<'_>, but it crashed rustc (big report was denied because apparently compiler crashes with intrinsics are not tracked). Is it possible to solve #121001 by detecting at compile time when the Arguments is one of these cases?

 pub const fn as_str(&self) -> Option<&'static str> {
match (self.pieces, self.args) {
([], []) => Some(""),
([s], []) => Some(s),
_ => None,
}
}

I think so. I'll have to look at #121001 more before I give you a precise answer, but there is a general trick for detecting a rare special case.

let a:bool = evaluateCondition();ifis_val_statically_known(a) && a {handleSpecialCase();}else{handleGeneralCase();}

Note that evaluateCondition() is ran regardless of the result of is_val_statically_known(a). If the optimizer recognizes that evaluateCondition() has no side effects, then it will likely be able to elide it after it resolves is_val_statically_known(a) to a boolean.

If I understand your code correctly, evaluateCondition() should be replaced by self.pieces.len() == 0. And of course you can replace the if-else with a match. As I mentioned I'll have to take a closer look later.

[nyurik]

Thanks @NCGThompson ! It turns out i could reuse an existing function that returns Option<&str>, and run is_val_statically_known(val.is_some)! I was just really confused why I got a compiler crash (rather than a regular diagnostics error). Now it all makes sense :)

See https://github.com/rust-lang/rust/pull/121001/files#diff-79bafab5831564f0d33567cf953a0c6cb70c66ed5db55a70fb39f485c48858aeR445-R449