[PATCH] D151638: [TRE] icmp does not escape an alloca

Joshua Cao via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 29 11:20:35 PDT 2023


caojoshua added a comment.

I also think that icmp should not leak provenance. However, after looking at your example, I think TRE actually **does** care about address capture. If the address is captured by another pointer such as `%p2` in your example, and we pass that pointer as an argument to a capturing call, `%p` is also captured and we can't mark tail calls. In this case, my patch is incorrect.

> This should be implemented in CaptureTracking first and foremost. TRE can be adjusted afterwards, or preferably should use CaptureTracking as well, instead of doing its own, incorrect reimplementation.
> Just considering all icmps non-escaping is obviously wrong. The property you are looking for here is that if you have an icmp where both sides are at some offset of the same underlying object, then the icmp will only compare the offsets and not leak any bits of the pointer, and as such is not capturing.

Extending CaptureTracking to support icmp's of pointers with the same underlying object seems like a reasonable choice. TRE's ad-hoc escape analysis has some specifics that may make it non-trivial to port to CaptureTracking, but we can look at that afterwards.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151638/new/

https://reviews.llvm.org/D151638



More information about the llvm-commits mailing list