[all-commits] [llvm/llvm-project] 3dfa86: [mlir][IR] Refactor the internal implementation of...

[River Riddle via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3dfa86149e14ebb7fa40c55749ae435641940ff6
      https://github.com/llvm/llvm-project/commit/3dfa86149e14ebb7fa40c55749ae435641940ff6
  Author: River Riddle <riddleriver at gmail.com>
  Date:   2021-03-03 (Wed, 03 Mar 2021)

  Changed paths:
    M mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h
    M mlir/include/mlir/IR/Operation.h
    M mlir/include/mlir/IR/OperationSupport.h
    M mlir/include/mlir/IR/TypeRange.h
    M mlir/include/mlir/IR/TypeUtilities.h
    M mlir/include/mlir/IR/Value.h
    M mlir/include/mlir/Interfaces/InferTypeOpInterface.td
    M mlir/include/mlir/Transforms/DialectConversion.h
    M mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp
    M mlir/lib/Dialect/Async/IR/Async.cpp
    M mlir/lib/IR/Operation.cpp
    M mlir/lib/IR/OperationSupport.cpp
    M mlir/lib/IR/TypeRange.cpp
    M mlir/lib/IR/TypeUtilities.cpp
    M mlir/lib/IR/Value.cpp
    M mlir/lib/Transforms/Utils/DialectConversion.cpp

  Log Message:
  -----------
  [mlir][IR] Refactor the internal implementation of Value

The current implementation of Value involves a pointer int pair with several different kinds of owners, i.e. BlockArgumentImpl*, Operation *, TrailingOpResult*. This design arose from the desire to save memory overhead for operations that have a very small number of results (generally 0-2). There are, unfortunately, many problematic aspects of the current implementation that make Values difficult to work with or just inefficient.

Operation result types are stored as a separate array on the Operation. This is very inefficient for many reasons: we use TupleType for multiple results, which can lead to huge amounts of memory usage if multi-result operations change types frequently(they do). It also means that simple methods like Value::getType/Value::setType now require complex logic to get to the desired type.

Value only has one pointer bit free, severely limiting the ability to use it in things like PointerUnion/PointerIntPair. Given that we store the kind of a Value along with the "owner" pointer, we only leave one bit free for users of Value. This creates situations where we end up nesting PointerUnions to be able to use Value in one.

As noted above, most of the methods in Value need to branch on at least 3 different cases which is both inefficient, possibly error prone, and verbose. The current storage of results also creates problems for utilities like ValueRange/TypeRange, which want to efficiently store base pointers to ranges (of which Operation* isn't really useful as one).

This revision greatly simplifies the implementation of Value by the introduction of a new ValueImpl class. This class contains all of the state shared between all of the various derived value classes; i.e. the use list, the type, and the kind. This shared implementation class provides several large benefits:

* Most of the methods on value are now branchless, and often one-liners.

* The "kind" of the value is now stored in ValueImpl instead of Value
This frees up all of Value's pointer bits, allowing for users to take full advantage of PointerUnion/PointerIntPair/etc. It also allows for storing more operation results as "inline", 6 now instead of 2, freeing up 1 word per new inline result.

* Operation result types are now stored in the result, instead of a side array
This drops the size of zero-result operations by 1 word. It also removes the memory crushing use of TupleType for operations results (which could lead up to hundreds of megabytes of "dead" TupleTypes in the context). This also allowed restructured ValueRange, making it simpler and one word smaller.

This revision does come with two conceptual downsides:
* Operation::getResultTypes no longer returns an ArrayRef<Type>
This conceptually makes some usages slower, as the iterator increment is slightly more complex.
* OpResult::getOwner is slightly more expensive, as it now requires a little bit of arithmetic

>From profiling, neither of the conceptual downsides have resulted in any perceivable hit to performance. Given the advantages of the new design, most compiles are slightly faster.

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