[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