Reduce the amount of interning and layout_of calls in const eval.

[oli-obk]

r? @ghost

If we just want to get at some bits of a constant, we don't need to intern it before extracting those bits.
Also, if we want to read a usize or bool, we can fetch the size without invoking a query.

[oli-obk]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 60d032b3f389e3f34d175d0e71658b5ec5e3c85f with merge 5585d82a144a6885bbd224d4aa643c0c95d39fb6...

[oli-obk]

cc @rust-lang/wg-const-eval

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 5585d82a144a6885bbd224d4aa643c0c95d39fb6 (5585d82a144a6885bbd224d4aa643c0c95d39fb6)

[rust-timer]

Queued 5585d82a144a6885bbd224d4aa643c0c95d39fb6 with parent 5db778a, future comparison URL.

[rust-timer]

Finished benchmarking try commit (5585d82a144a6885bbd224d4aa643c0c95d39fb6): comparison url.

[oli-obk]

booya 5% perf improvement

r? @RalfJung

[oli-obk]

@bors rollup=never

[RalfJung]

This looks pretty different from the old code, is all I can say here.^^ No idea if it changes behavior.

[oli-obk]

this is not the same function. The same function invokes this function adn handles all the cases just like they are handled here.

[RalfJung]

I have not seen most of this code ever before, so I do not think I can meaningfully review this. I don't even understand how this reduces interning or layout_of...
I know Miri well, but that is really restricted to the stuff in the intepret folders. Everything outside is code I barely ever touch or look at. And when I look at it I am usually confused. ;)

Wow, we have Const and ConstKind and ConstValue? That's way more confusing than I remembered. Particularly great is that Const is described as a "Typed constant value" but contains a ConstKind...

[oli-obk]

I don't even understand how this reduces interning or layout_of...

layout_of invocations are reduced by knowing that the size of usize and bool is tcx.data_layout.pointer_size and Size::from_bytes(1) respectively.

Interning is reduced by evaluating ConstValue instead of ty::Const where we just throw away the ty::Const anyway in order to get at inner values.

[RalfJung]

Interning is reduced by evaluating ConstValue instead of ty::Const where we just throw away the ty::Const anyway in order to get at inner values.

Which entry points, concretely, do you mean here? I tried to follow the code in the diff a bit but it is rather hard. There's a dozen functions on 2-3 different types that are all called the same, and when looking at a fn foo you cannot even tell which type self has.^^

[oli-obk]

reduces interning

[oli-obk]

This also reduces layout_of invocations, because instead of invoking that on tcx.types.usize, we just use the size in try_to_machine_usize

[oli-obk]

This is used in a mir optimization on every single Assert terminator:

rust/src/librustc_mir/transform/simplify_branches.rs

Line 53 in f9fdf64

}if(c.literal.try_eval_bool(tcx, param_env) == Some(true)) == expected => {

[oli-obk]

This is used all over the place for array lengths

[RalfJung]

Oh so on Const we have try_eval_bits and eval but they do not call each other, and there is neither eval_bits nor try_eval. But try_eval exists on ConstKind. But it is not used to implement Const::try_eval_bits, at least not directly... I feel I need to draw a call graph by hand to understand what happens.

[RalfJung]

Longer-term I feel like this is really the thing that ought to be called Const, and the existing Const should become ConstAndTy or so... but that is for a separate PR.

[bors]

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

[RalfJung]

r=me after rebasing.

[oli-obk]

@bors r=RalfJung

[bors]

📌 Commit 1bf0993 has been approved by RalfJung

[bors]

⌛ Testing commit 1bf0993 with merge 125c58c...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: RalfJung
Pushing 125c58c to master...

[nnethercote]

The perf results from landing don't quite match the earlier results. It's still a win for wf-projection-stress-65510, but it's up to a 2% loss for clap-rs, and a fraction of 1% loss for numerous benchmarks.

@oli-obk: did anything change between the earlier run and landing that might explain these worse results?

[oli-obk]

The only thing could be some changes around inlining due to the restructuring of the modules, but I don't think this should have an effect within a single crate. If I click the red percentages to look at the details, these regressions aren't actually reflected in the detailed view (or I don't know how to read the detailed view).

[mati865]

encode_query_results_for is where the regression is coming from.

[oli-obk]

While there's indeed a 1.6% regression in encode_query_results_for, there's a 40% improvement because we now stop invoking the typeck_tables_of query. https://perf.rust-lang.org/detailed-query.html?commit=125c58caebc67c32ec45ac6c0581b596fd532082&base_commit=4cd0ee9343da86d9770bf0a514a682d240e0dce8&benchmark=clap-rs-check&run_name=incr-unchanged shows nothing of the 2% regression that is shown in the main view

[oli-obk]

Ah, no I see now. Incremental loading and execution are separated. And apparently loading typeck_tables_of takes 4.0% more time than computing it 👀

[mati865]

typeck_tables_of time was marginal so improvement's here aren't terribly beneficial.
encode_query_results_for alone takes 1/3 of the total time so when you add it's 1.6% regression to other smaller regressions it starts to become visible in the final result.