[PATCH] D132084: [Cloning] handle blockaddress array clone in the same module
Yuanfang Chen via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 19 10:48:21 PDT 2022
ychen added a comment.
In D132084#3733512 <https://reviews.llvm.org/D132084#3733512>, @efriedma wrote:
>> Thanks, I see your point now. The issue is indeed not solvable in general for the reason you mentioned, but for certain commonly used patterns like global blockaddress array, it is legal to clone since each element of such array could not be shared by functions.
>
> You'd have to prove that values loaded from the array don't escape the function, which seems difficult to prove in cases where I'd expect to see blockaddress used.
That's right. Maybe just handle the case where blockaddress is been written at all?
>> the current situation of silently creating broken IR when cloning blockaddress is not ideal.
>
> I'm not sure what invariant we can enforce here. Maybe something related to the CloneFunctionChangeType?
That's hard in general and feels insufficient to just handle some cases but not the others. How about emit a warning of sorts all the way back to the frontend? Also add a boolean flag for CloneFunction API to optionally call IndirectBrExpandPass's logic.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D132084/new/
https://reviews.llvm.org/D132084
More information about the llvm-commits
mailing list