[PATCH] D66461: [CaptureTracker] Comparisons of allocation pointers do not capture
Johannes Doerfert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 22 13:15:23 PDT 2019
jdoerfert added a comment.
In D66461#1641668 <https://reviews.llvm.org/D66461#1641668>, @efriedma wrote:
> > As I described, the compare will capture only if the other pointer was captured. So additionally to the checks in the patch ask the tracker if that is the case
>
> You can't actually reconstruct the pointer in that case, but the bits are still significant; if two functions sort a list of pointers, they have to sort the same way. Whether that means the pointer is "captured" depends on the definition of "captured"; I can think of transforms that don't care, and transforms that do care.
You lost me. When I say "captured" I mean (a bit of) the pointer value is leaked. When I above said you have two pointers, if neither is captured so far a comparison between them doesn't capture either I mean that we do not need to worry about the bits being leaked and later used to access the memory or doing other odd things.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D66461/new/
https://reviews.llvm.org/D66461
More information about the llvm-commits
mailing list