Don't use eval_always for miri queries used from codegen.

[eddyb]

This should fix the massive incremental perf regression introduced in #65664.

It seems that eval_always was mistakenly(?) added to const_field and then it ended up on const_caller_location (which is used much more often than const_field is).

r? @michaelwoerister cc @oli-obk @nnethercote

[eddyb]

@bors rollup=never p=10 (ideally we can land it in time for the next nightly)

[michaelwoerister]

@bors r+

[bors]

📌 Commit beb06ae has been approved by michaelwoerister

[bors]

⌛ Testing commit beb06ae with merge d3d28a4...

[bors]

☀️ Test successful - checks-azure
Approved by: michaelwoerister
Pushing d3d28a4 to master...

[eddyb]

@rust-timer build eb5ef81

(I'm trying to prioritize the build just before this PR, to get the perf diff data sooner)

[rust-timer]

Queued eb5ef81 with parent 2dd4e73, future comparison URL.

[eddyb]

Comparisons I'm interested in:

• before the rollup -> after this PR
  • data already available, and most of the regression is gone
  • the remaining regressions could be from unrelated changes
• after the rollup -> before this PR
  • not done yet, the end commit of that is what I prioritized above
  • this should contain the remaining regressions, assuming they're unrelated

[nnethercote]

If you look at just the check builds in the original perf regression (use the "filter" box near the top) the only entry of note is this:

packed-simd-check | avg: 2.9% | min: 2.2% | max: 4.2%

So the packed-simd regressions remain and are from #65664. The other slight regressions (e.g. piston-image-opt, keccak-debug) are likely from different PRs.

[eddyb]

Wait, check? From #65664? Are there a lot of panic!()s being expanded or something?

We went the way we did was to avoid having an (unsafe) intrinsic call from panic!, and also because the intrinsic would have to handle being used from a macro better, but I could try getting that to work tomorrow, if that regression is considered important.

EDIT: opened #65973 for that packed-simd-* regression.

[nnethercote]

2-4% is non-trivial, so if there's a way to recover from it that would be great.

[eddyb]

Interestingly enough, packed-simd-* also regressed between the rollup and the fix.
But not as much, and not on incremental runs, so it's likely a smaller, and different, regression.
EDIT: from what data is already in perf, the smaller regression can be narrowed down to this range.
EDIT2: looking at the two rollups that make the remaining "small regression" range, #65294 is the only one that I would guess had anything to do with it, but I'm unsure.