[PATCH] D72020: [mlir] Rewrite the internal representation of OpResult to be optimized for memory.

[River Riddle via Phabricator via llvm-commits]

rriddle created this revision.
rriddle added a reviewer: jpienaar.
Herald added subscribers: llvm-commits, nicolasvasilache, antiagainst, shauheen, burmako, mehdi_amini.
Herald added a project: LLVM.

This changes the implementation of OpResult to have some of the results be represented inline in Value, via a pointer int pair of Operation*+result number, and the rest being trailing objects on the main operation. The full details of the new representation is detailed in the proposal here:
https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ

The only difference between here and the above proposal is that we only steal 2-bits for the Value kind instead of 3. This means that we can only fit 2-results inline instead of 6. This allows for other users to steal the final bit for PointerUnion/etc. If necessary, we can always steal this bit back in the future to save more space if 3-6 results are common enough.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72020

Files:
  mlir/include/mlir/IR/Operation.h
  mlir/include/mlir/IR/OperationSupport.h
  mlir/include/mlir/IR/Value.h
  mlir/include/mlir/Support/STLExtras.h
  mlir/lib/IR/Operation.cpp
  mlir/lib/IR/OperationSupport.cpp
  mlir/lib/IR/Value.cpp
  mlir/test/lib/Transforms/TestInlining.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D72020.235652.patch
Type: text/x-patch
Size: 36534 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191230/5ce0ef4b/attachment-0001.bin>