This is an archive of the discontinued LLVM Phabricator instance.

[CaptureTracking] Allow non-void `noalias` return funcs to be non-capturing
AbandonedPublic

Authored by goldstein.w.n on Aug 1 2023, 6:44 PM.

Details

Summary

This only applies for readonly/nounwind functions from which capturing
can only happen via the return value. If the return is noalias, its
guranteed to not be based on any incoming pointer argument so is safe
to be assumed not to be capturing.

Diff Detail

Unit TestsFailed

Event Timeline

goldstein.w.n created this revision.Aug 1 2023, 6:44 PM
goldstein.w.n requested review of this revision.Aug 1 2023, 6:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 1 2023, 6:44 PM
nikic requested changes to this revision.Aug 14 2023, 3:56 AM

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.

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.

This revision now requires changes to proceed.Aug 14 2023, 3:56 AM
goldstein.w.n abandoned this revision.Aug 14 2023, 8:34 AM

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.