Experiment in removing ptr->int->ptr casts #7664
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While looking over
clang-tidy
checks that we had disabled, I came acrossperformance-no-int-to-ptr
and ended up in a fascinating rabbit hole. TL;DR: doing ptr->int->ptr casting reduces opportunities for compiler optimizations (and that's what this check attempts to warn you about). I had no idea this was even a thing, but https://www.ralfj.de/blog/2020/12/14/provenance.html and https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html provided interesting backstory.Running clang-tidy with this enabled revealed a lot of places in our runtime code that might run afoul of this... but it's not clear whether any of them are on a critical path that makes this inefficiency critical (except, perhaps, for the bit-tagging we do in
synchronization_common
).Anyway, I experimentally converted a few places to follow what I think are the right guidelines (and they no longer trigger this check). Not sure if this is worth pursuing any further, but I thought it worthwhile to post here as a Draft for people to take a look at.