-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce ConstAllocation
.
#94597
Introduce ConstAllocation
.
#94597
Conversation
Some changes occured to rustc_codegen_gcc cc @antoyo Some changes occured to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in src/tools/clippy. cc @rust-lang/clippy Some changes occured to rustc_codegen_cranelift cc @bjorn3 Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
This is the next step after #93148. |
I don't expect this to have much effect on performance, but let's check. @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 904767d40562bb4e5775232d903c6a654f91cccd with merge 3cf02802d38ab3495d18e703694f862dd416f888... |
☀️ Try build successful - checks-actions |
Queued 3cf02802d38ab3495d18e703694f862dd416f888 with parent 8fa5d74, future comparison URL. |
Finished benchmarking commit (3cf02802d38ab3495d18e703694f862dd416f888): comparison url. Summary: This benchmark run shows 15 relevant improvements 🎉 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. 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 led to changes in compiler perf. @bors rollup=never |
No objection from my side. I was at first a bit confused since it wasn't clear that |
It seems like "const" might be referring to either somehow |
It's the first. Some of these allocations will be mutable at runtime, that is controlled by a flag inside |
Hm. I guess I don't fully understand the distinction, then. The comment on ConstAllocation says nothing about I would expect that runtime mutability is indeed distinct from immutability of the allocation at compile time -- do we only intern top-level allocations (for some definition of top-level, perhaps those associated with a DefId)? (My opinions here aren't blockers or that strong, of course -- feel free to tell me that the name will be obvious for those working with this part of the compiler often). |
These were already being called "const allocations" (e.g. pre-existing |
Nice to see this was a small instruction win for a few cases. Though cycles and wall-time didn't change in any significant way, so maybe it is perf-neutral in practice. |
OK -- then since this is already being used elsewhere, seems OK to continue using it for now. We can consider a rename later down the line if it turns out that it is confusing for more than just me :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me after nit
@@ -1434,7 +1435,7 @@ pub trait PrettyPrinter<'tcx>: | |||
// The `inspect` here is okay since we checked the bounds, and there are no | |||
// relocations (we have an active `str` reference here). We don't use this | |||
// result to affect interpreter execution. | |||
let slice = data.inspect_with_uninit_and_ptr_outside_interpreter(start..end); | |||
let slice = data.0.inspect_with_uninit_and_ptr_outside_interpreter(start..end); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps using inner
like everywhere else would be more consistent here?
@bors delegate+ |
✌️ @nnethercote can now approve this pull request |
Currently some `Allocation`s are interned, some are not, and it's very hard to tell at a use point which is which. This commit introduces `ConstAllocation` for the known-interned ones, which makes the division much clearer. `ConstAllocation::inner()` is used to get the underlying `Allocation`. In some places it's natural to use an `Allocation`, in some it's natural to use a `ConstAllocation`, and in some places there's no clear choice. I've tried to make things look as nice as possible, while generally favouring `ConstAllocation`, which is the type that embodies more information. This does require quite a few calls to `inner()`. The commit also tweaks how `PartialOrd` works for `Interned`. The previous code was too clever by half, building on `T: Ord` to make the code shorter. That caused problems with deriving `PartialOrd` and `Ord` for `ConstAllocation`, so I changed it to build on `T: PartialOrd`, which is slightly more verbose but much more standard and avoided the problems.
904767d
to
4852291
Compare
@bors r=fee1-dead |
📌 Commit 4852291 has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@8876ca3. Direct link to PR: <rust-lang/rust#94597> 💔 miri on windows: test-pass → build-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @eddyb @RalfJung).
Finished benchmarking commit (8876ca3): comparison url. Summary: This benchmark run shows 13 relevant improvements 🎉 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Currently some
Allocation
s are interned, some are not, and it's veryhard to tell at a use point which is which.
This commit introduces
ConstAllocation
for the known-interned ones,which makes the division much clearer.
ConstAllocation::inner()
isused to get the underlying
Allocation
.In some places it's natural to use an
Allocation
, in some it's naturalto use a
ConstAllocation
, and in some places there's no clear choice.I've tried to make things look as nice as possible, while generally
favouring
ConstAllocation
, which is the type that embodies moreinformation. This does require quite a few calls to
inner()
.The commit also tweaks how
PartialOrd
works forInterned
. Theprevious code was too clever by half, building on
T: Ord
to make thecode shorter. That caused problems with deriving
PartialOrd
andOrd
for
ConstAllocation
, so I changed it to build onT: PartialOrd
,which is slightly more verbose but much more standard and avoided the
problems.
r? @fee1-dead