[all-commits] [llvm/llvm-project] b1cd39: [AA] Tracking per-location ModRef info in Function...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b1cd393f9e3a547b315f98a73807d8eaccf600bf
      https://github.com/llvm/llvm-project/commit/b1cd393f9e3a547b315f98a73807d8eaccf600bf
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2022-09-14 (Wed, 14 Sep 2022)

  Changed paths:
    M llvm/include/llvm/Analysis/AliasAnalysis.h
    M llvm/lib/Analysis/AliasAnalysis.cpp
    M llvm/lib/Analysis/AliasSetTracker.cpp
    M llvm/lib/Analysis/BasicAliasAnalysis.cpp
    M llvm/lib/Analysis/GlobalsModRef.cpp
    M llvm/lib/Analysis/ObjCARCAliasAnalysis.cpp
    M llvm/lib/Analysis/TypeBasedAliasAnalysis.cpp
    M llvm/lib/Transforms/IPO/FunctionAttrs.cpp
    M llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
    M llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
    M llvm/lib/Transforms/ObjCARC/DependencyAnalysis.cpp
    M llvm/lib/Transforms/Scalar/LICM.cpp
    M llvm/lib/Transforms/Utils/InlineFunction.cpp
    M llvm/unittests/Analysis/GlobalsModRefTest.cpp
    M polly/lib/Analysis/ScopBuilder.cpp
    M polly/lib/Analysis/ScopDetection.cpp

  Log Message:
  -----------
  [AA] Tracking per-location ModRef info in FunctionModRefBehavior (NFCI)

Currently, FunctionModRefBehavior tracks whether the function reads
or writes memory (ModRefInfo) and which locations it can access
(argmem, inaccessiblemem and other). This patch changes it to track
ModRef information per-location instead.

To give two examples of why this is useful:

* D117095 highlights a weakness of ModRef modelling in the presence
  of operand bundles. For a memcpy call with deopt operand bundle,
  we want to say that it can read any memory, but only write argument
  memory. This would allow them to be treated like any other calls.
  However, we currently can't express this and have to say that it
  can read or write any memory.
* D127383 would ideally be modelled as a separate threadid location,
  where threadid Refs outside pre-split coroutines can be ignored
  (like other accesses to constant memory). The current representation
  does not allow modelling this precisely.

The patch as implemented is intended to be NFC, but there are some
obvious opportunities for improvements and simplification. To fully
capitalize on this we would also want to change the way we represent
memory attributes on functions, but that's a larger change, and I
think it makes sense to separate out the FunctionModRefBehavior
refactoring.

Differential Revision: https://reviews.llvm.org/D130896