we are preparing for the code review of the full restrict patches. [0, 1]
During the latest LLVM Alias Analysis Technical Call[2,3], I already checked with the attendees
if there were any objections against/concerns about the general high level approach. (there were none)
(The RFC and the first patch describe this approach;  is up to date
with the current state)
I also want to check this again with the broader LLVM community: if you have
any objections against/concerns about the approach taken, let us know now.
The current plan is the following:
by next LLVM Alias Analysis Technical call (September 8):
- add the missing implementation for LLVM IR bitcode support
- rebase the patches to a more recent top-of-tree
- start reviewing the patches, one by one:
-- They are applicable in the provided order
-- As long as the full restrict features are not used, they should not impact the existing flow too much.
If you have concerns with some part of the implementation, you can help us with the code reviews.
 RFC: Full 'restrict' support in LLVM: https://lists.llvm.org/pipermail/llvm-dev/2019-October/135672.html
 First patch of the series: https://reviews.llvm.org/D68484
 LLVM Alias Analysis Technical call: https://lists.llvm.org/pipermail/llvm-dev/2020-August/144237.html
 LLVM Alias Analysis Technical call: google docs: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing