Hi all,
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[0] and the first patch[1] describe this approach; [1] 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.
Thanks,
Jeroen Dobbelaere
[0] RFC: Full 'restrict' support in LLVM: [llvm-dev] [repost] RFC: Full 'restrict' support in LLVM
[1] First patch of the series: ⚙ D68484 [PATCH 01/27] [noalias] LangRef: noalias intrinsics and ptr_provenance documentation.
[2] LLVM Alias Analysis Technical call: [llvm-dev] LLVM Alias Analysis Technical Call - New Doodle Poll
[3] LLVM Alias Analysis Technical call: google docs: LLVM AA Technical Call - Google Docs