[PATCH] D130980: [AA] Model operand bundles more precisely

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 1 08:01:40 PDT 2022


reames added a comment.

In D130980#3763305 <https://reviews.llvm.org/D130980#3763305>, @nikic wrote:

> In D130980#3762564 <https://reviews.llvm.org/D130980#3762564>, @reames wrote:
>
>> Replying only to this text from your description:
>> "For example, a memcpy with deopt bundle can read and write argument memory, but only read inaccessible and other memory."
>>
>> I can't quite parse exactly what you mean here, but it *sounds* like you're saying the deopt bundle isn't allowed to read arbitrary (captured) memory.  If so, we've talked ourselves into a bad result, because that's exactly what deopt needs to do.
>>
>> Conceptually, "deopt" captures the abstract machine state of the running thread.  The arguments to deopt are obviously part of that, but so is any memory which is a) visible from another thread, or b) visible from any of the captured state.  So, in general, a deopt operand needs to read all memory which we can't *explicitly* prove hasn't been captured at or before the call.
>
> The phrasing here was unnecessarily confusing. What we want to model is that memcpy+deopt can read any memory and write argument memory. Importantly, this excludes *writing* to captured memory.

Ah, glad to hear we're on the same page.


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

https://reviews.llvm.org/D130980



More information about the llvm-commits mailing list