[PATCH] D156841: [CaptureTracking] Allow non-void `noalias` return funcs to be non-capturing

Mon Aug 14 08:34:37 PDT 2023

goldstein.w.n abandoned this revision.
goldstein.w.n added a comment.

In D156841#4584404 <https://reviews.llvm.org/D156841#4584404>, @nikic wrote:

> I don't think this is correct. `noalias` is a provenance concept, while `nocapture` is also about address identity.
>
> For example, realloc-style functions usually also have noalias return, even though they might return the same pointer as their argument. After such a realloc, it is no longer legal to make accesses through the old pointer, even though it has the same address as the new one.
>
> Lets say you have a special realloc function that guarantees that it returns the original pointer (with fresh provenance) if the allocation size does not change. In that case `realloc(p, old_size) == p` must return true, so realloc captures the pointer.

Ah thats a good point.

> There are some confounding factors here, because we do have at least one optimization that tries to assign address unpredictabliity properties to noalias returns, but I believe the general consensus is that that optimization is buggy, and this should be represented using a separate allocator property instead.
>
> Anyway, what's the motivation for this? I can't come up with an example where you would run into a function that is both noalias and readonly in practice.

Same as my other `nocapture` patch. I really want a way to be able `nocapture` to some inline syscalls and realized I can get it with noalias.
But fine dropping this. I'm waiting on the light attributor codes to get into upstream then will hopefully integrate the callsite tracking patch
I have.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156841