- Round Table was held on November 9, 2022 at the LLVM Dev Conference in San Jose.
- 15+ participants of various companies/projects
- Question about possibility of getting compiler warnings when restrict is used in an invalid way
=> this is not the goal of the full restrict patches. Solving this statically is a hard problem and can only work for simple cases. (gcc is giving some warnings)
=> Something like type sanitizer can be created.
=> Getting warnings from within llvm reported to clang is possible but might need extra infrastructure. - Johannes: about ORAQL: program + testcases; optimistically answering alias queries, validated with the testcases;
Gives an upper bound on what can be achieved if all information is available for resolving alias queries.
Can show places where optimizations are missing. (aka, sometimes more performance increase would be expected than
what is observed) - Full Restrict Patches
- Due to various reasons progress in actively reviewing the patches was slow over the past year.
- Discussion about willingness to have the full restrict changes in the main version. Everyone at the round table agrees we should proceed.
- Google has done some extensive testing; did not observe any regressions (errors, nor quality)
- Current state:
- Single all-containing convenience full restrict patch (⚙ D69542 Full Restrict Support - single patch)
Updated every few months (most recent update at June 29, 2022)
This is not for review; Just to provide access to the full version. - Current focus is on remaining basic infrastructure enhancements: introduction of ptr_provenance.
- The stack of ⚙ D111163 [UnknownProvenance] add support in ValueMapper tracks the current outstanding ptr_provenance changes.
- Once that part is in, the remaining work is ‘just work’ and should be less controversial.
- For more information about how it works, see the talk in LLVM Developers Conference of 2021:
‘ptr_provenance and @llvm.noalias: The Tale of Full Restrict’
( https://www.llvm.org/devmtg/2021-11/slides/2021-ptr_provenanceAndLlvmNoaliasTheTaleOfFullRestrict.pdf )
(Youtube, high quality: 21 1118 1145 TT Dobbelaere v2 22 0116 - YouTube )
- Single all-containing convenience full restrict patch (⚙ D69542 Full Restrict Support - single patch)
- The full restrict infrastructure is focused on ‘restrict’; In this form or with some small adaptations
it could be useful to accommodate for the needs of rust, flang, ‘c++ alias_set’ proposal, …
- Further discussion can be done during the LLVM AA TechCalls or on discourse.
- There was consensus on more actively working on patches and asking for reviews to get progress.
Jeroen Dobbelaere