Skip to content
  1. Dec 02, 2020
  2. Nov 26, 2020
  3. Nov 25, 2020
    • Aart Bik's avatar
      [mlir][sparse] add parallelization strategies to sparse compiler · 5c4e397e
      Aart Bik authored
      This CL adds the ability to request different parallelization strategies
      for the generate code. Every "parallel" loop is a candidate, and converted
      to a parallel op if it is an actual for-loop (not a while) and the strategy
      allows dense/sparse outer/inner parallelization.
      
      This will connect directly with the work of @ezhulenev on parallel loops.
      
      Still TBD: vectorization strategy
      
      Reviewed By: penpornk
      
      Differential Revision: https://reviews.llvm.org/D91978
      5c4e397e
  4. Nov 24, 2020
  5. Nov 23, 2020
  6. Nov 21, 2020
  7. Nov 20, 2020
  8. Nov 19, 2020
  9. Nov 17, 2020
  10. Nov 14, 2020
  11. Nov 13, 2020
  12. Nov 12, 2020
    • Sean Silva's avatar
      [mlir] Bufferize tensor constant ops · faa66b1b
      Sean Silva authored
      We lower them to a std.global_memref (uniqued by constant value) + a
      std.get_global_memref to produce the corresponding memref value.
      This allows removing Linalg's somewhat hacky lowering of tensor
      constants, now that std properly supports this.
      
      Differential Revision: https://reviews.llvm.org/D91306
      faa66b1b
    • Sean Silva's avatar
      [mlir] Fix subtensor_insert bufferization. · ad2f9f67
      Sean Silva authored
      It was incorrect in the presence of a tensor argument with multiple
      uses.
      
      The bufferization of subtensor_insert was writing into a converted
      memref operand, but there is no guarantee that the converted memref for
      that operand is safe to write into. In this case, the same converted
      memref is written to in-place by the subtensor_insert bufferization,
      violating the tensor-level semantics.
      
      I left some comments in a TODO about ways forward on this. I will be
      working actively on this problem in the coming days.
      
      Differential Revision: https://reviews.llvm.org/D91371
      ad2f9f67
    • MaheshRavishankar's avatar
      [mlir][Linalg] Improve the logic to perform tile and fuse with better dependence tracking. · 5ca20851
      MaheshRavishankar authored
      This change does two main things
      1) An operation might have multiple dependences to the same
         producer. Not tracking them correctly can result in incorrect code
         generation with fusion. To rectify this the dependence tracking
         needs to also have the operand number in the consumer.
      2) Improve the logic used to find the fused loops making it easier to
         follow. The only constraint for fusion is that linalg ops (on
         buffers) have update semantics for the result. Fusion should be
         such that only one iteration of the fused loop (which is also a
         tiled loop) must touch only one (disjoint) tile of the output. This
         could be relaxed by allowing for recomputation that is the default
         when oeprands are tensors, or can be made legal with promotion of
         the fused view (in future).
      
      Differential Revision: https://reviews.llvm.org/D90579
      5ca20851
    • Aart Bik's avatar
      [mlir][sparse] integrate sparse annotation into generic linalg op · e1dbc25e
      Aart Bik authored
      This CL integrates the new sparse annotations (hereto merely added as fully
      transparent attributes) more tightly to the generic linalg op in order to add
      verification of the annotations' consistency as well as to make make other
      passes more aware of their presence (in the long run, rewriting rules must
      preserve the integrity of the annotations).
      
      Reviewed By: nicolasvasilache
      
      Differential Revision: https://reviews.llvm.org/D91224
      e1dbc25e
  13. Nov 10, 2020
    • Sean Silva's avatar
      [mlir] Add pass to convert elementwise ops to linalg. · 53a0d45d
      Sean Silva authored
      This patch converts elementwise ops on tensors to linalg.generic ops
      with the same elementwise op in the payload (except rewritten to
      operate on scalars, obviously). This is a great form for later fusion to
      clean up.
      
      E.g.
      
      ```
      // Compute: %arg0 + %arg1 - %arg2
      func @f(%arg0: tensor<?xf32>, %arg1: tensor<?xf32>, %arg2: tensor<?xf32>) -> tensor<?xf32> {
        %0 = addf %arg0, %arg1 : tensor<?xf32>
        %1 = subf %0, %arg2 : tensor<?xf32>
        return %1 : tensor<?xf32>
      }
      ```
      
      Running this through
      `mlir-opt -convert-std-to-linalg -linalg-fusion-for-tensor-ops` we get:
      
      ```
      func @f(%arg0: tensor<?xf32>, %arg1: tensor<?xf32>, %arg2: tensor<?xf32>) -> tensor<?xf32> {
        %0 = linalg.generic {indexing_maps = [#map0, #map0, #map0, #map0], iterator_types = ["parallel"]} ins(%arg0, %arg1, %arg2 : tensor<?xf32>, tensor<?xf32>, tensor<?xf32>) {
        ^bb0(%arg3: f32, %arg4: f32, %arg5: f32):  // no predecessors
          %1 = addf %arg3, %arg4 : f32
          %2 = subf %1, %arg5 : f32
          linalg.yield %2 : f32
        } -> tensor<?xf32>
        return %0 : tensor<?xf32>
      }
      ```
      
      So the elementwise ops on tensors have nicely collapsed into a single
      linalg.generic, which is the form we want for further transformations.
      
      Differential Revision: https://reviews.llvm.org/D90354
      53a0d45d
  14. Nov 09, 2020
  15. Nov 04, 2020
    • Sean Silva's avatar
      [mlir] Make linalg-bufferize a composable bufferization pass · eb8d386d
      Sean Silva authored
      Previously, linalg-bufferize was a "finalizing" bufferization pass (it
      did a "full" conversion). This wasn't great because it couldn't be used
      composably with other bufferization passes like std-bufferize and
      scf-bufferize.
      
      This patch makes linalg-bufferize a composable bufferization pass.
      Notice that the integration tests are switched over to using a pipeline
      of std-bufferize, linalg-bufferize, and (to finalize the conversion)
      func-bufferize. It all "just works" together.
      
      While doing this transition, I ran into a nasty bug in the 1-use special
      case logic for forwarding init tensors. That logic, while
      well-intentioned, was fundamentally flawed, because it assumed that if
      the original tensor value had one use, then the converted memref could
      be mutated in place. That assumption is wrong in many cases. For
      example:
      
      ```
        %0 = some_tensor : tensor<4xf32>
        br ^bb0(%0, %0: tensor<4xf32>, tensor<4xf32>)
      ^bb0(%bbarg0: tensor<4xf32>, %bbarg1: tensor<4xf32>)
        // %bbarg0 is an alias of %bbarg1. We cannot safely write
        // to it without analyzing uses of %bbarg1.
        linalg.generic ... init(%bbarg0) {...}
      ```
      
      A similar example can happen in many scenarios with function arguments.
      Even more sinister, if the converted memref is produced by a
      `std.get_global_memref` of a constant global memref, then we might
      attempt to write into read-only statically allocated storage! Not all
      memrefs are writable!
      
      Clearly, this 1-use check is not a local transformation that we can do
      on the fly in this pattern, so I removed it.
      
      The test is now drastically shorter and I basically rewrote the CHECK
      lines from scratch because:
      - the new composable linalg-bufferize just doesn't do as much, so there
      is less to test
      - a lot of the tests were related to the 1-use check, which is now gone,
      so there is less to test
      - the `-buffer-hoisting -buffer-deallocation` is no longer mixed in, so
      the checks related to that had to be rewritten
      
      Differential Revision: https://reviews.llvm.org/D90657
      eb8d386d
    • mikeurbach's avatar
      [MLIR] Move eraseArguments and eraseResults to FunctionLike · 2e36e0da
      mikeurbach authored
      Previously, they were only defined for `FuncOp`.
      
      To support this, `FunctionLike` needs a way to get an updated type
      from the concrete operation. This adds a new hook for that purpose,
      called `getTypeWithoutArgsAndResults`.
      
      For now, `FunctionLike` continues to assume the type is
      `FunctionType`, and concrete operations that use another type can hide
      the `getType`, `setType`, and `getTypeWithoutArgsAndResults` methods.
      
      Reviewed By: rriddle
      
      Differential Revision: https://reviews.llvm.org/D90363
      2e36e0da
  16. Nov 03, 2020
  17. Oct 30, 2020
    • Sean Silva's avatar
      [mlir] Move some linalg patterns around. · 30e130c3
      Sean Silva authored
      The bufferization patterns are moved to the .cpp file, which is
      preferred in the codebase when it makes sense.
      
      The LinalgToStandard patterns are kept a header because they are
      expected to be used individually. However, they are moved to
      LinalgToStandard.h which is the file corresponding to where they are
      defined.
      
      This also removes TensorCastOpConverter, which is handled by
      populateStdBufferizePatterns now. Eventually, the constant op lowering
      will be handled as well, but it there are currently holdups on moving
      it (see https://reviews.llvm.org/D89916).
      
      Differential Revision: https://reviews.llvm.org/D90254
      30e130c3
  18. Oct 29, 2020
    • Nicolas Vasilache's avatar
      [mlir][Linalg] Make Linalg fusion a test pass · 9b17bf2e
      Nicolas Vasilache authored
      Linalg "tile-and-fuse" is currently exposed as a Linalg pass "-linalg-fusion" but only the mechanics of the transformation are currently relevant.
      Instead turn it into a "-test-linalg-greedy-fusion" pass which performs canonicalizations to enable more fusions to compose.
      This allows dropping the OperationFolder which is not meant to be used with the pattern rewrite infrastructure.
      
      Differential Revision: https://reviews.llvm.org/D90394
      9b17bf2e
  19. Oct 28, 2020
  20. Oct 27, 2020
    • River Riddle's avatar
      [mlir][Pattern] Add a new FrozenRewritePatternList class · 3fffffa8
      River Riddle authored
      This class represents a rewrite pattern list that has been frozen, and thus immutable. This replaces the uses of OwningRewritePatternList in pattern driver related API, such as dialect conversion. When PDL becomes more prevalent, this API will allow for optimizing a set of patterns once without the need to do this per run of a pass.
      
      Differential Revision: https://reviews.llvm.org/D89104
      3fffffa8
    • River Riddle's avatar
      [mlir][NFC] Move around the code related to PatternRewriting to improve layering · b6eb26fd
      River Riddle authored
      There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those pieces to a better location such that they are easier to evolve in the future(e.g. with PDL). More concretely this revision does the following:
      
      * Create a Transforms/GreedyPatternRewriteDriver.h and move the apply*andFold methods there.
      The definitions for these methods are already in Transforms/ so it doesn't make sense for the declarations to be in IR.
      
      * Create a new lib/Rewrite library and move PatternApplicator there.
      This new library will be focused on applying rewrites, and will also include compiling rewrites with PDL.
      
      Differential Revision: https://reviews.llvm.org/D89103
      b6eb26fd
Loading