[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