This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] Split arith dialect from the std dialect
ClosedPublic

Authored by Mogball on Sep 21 2021, 2:05 PM.

Details

Summary

Create the Arithmetic dialect that contains basic integer and floating
point arithmetic operations. Ops that did not meet this criterion were
moved to the Math dialect.

First of two atomic patches to remove integer and floating point
operations from the standard dialect. Ops will be removed from the
standard dialect in a subsequent patch.

Diff Detail

Event Timeline

Mogball created this revision.Sep 21 2021, 2:05 PM
Mogball requested review of this revision.Sep 21 2021, 2:05 PM
Mogball updated this revision to Diff 374056.Sep 21 2021, 3:30 PM
  • fixing build on CMake
Mogball updated this revision to Diff 374065.Sep 21 2021, 4:22 PM
  • clang-tidy errors
bondhugula added inline comments.
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticBase.td
20

ternery -> ternary

ftynse added inline comments.Sep 22 2021, 12:57 AM
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticBase.td
26–72

Does it make sense to expose this in user-visible documentation? These are ODS classes and they don't have C++ equivalents AFAIK, so I'd just keep this diagram as comment in the .td file for whoever needs to modify it and avoid having it rendered on mlir.llvm.org.

How about moving index -> index ops like arith.affine_apply,
arith.affine_min and arith.affing_max in here too ?
Not in this CL, I am checking the temperature on the idea as it will
simplify the layering of a bunch of stuff.

How about moving index -> index ops like arith.affine_apply,
arith.affine_min and arith.affing_max in here too ?
Not in this CL, I am checking the temperature on the idea as it will
simplify the layering of a bunch of stuff.

Aren't these very "affine" related (as their name indicates)? The fit isn't clear to me here.
I'm interested in understanding the layering aspect though!

silvas accepted this revision.Sep 22 2021, 9:49 AM

did a pass. looks good to me. probably want to wait for a handful of LGTM's given the far-reaching consequences of this change. Ideally both River and Chris could weigh in.

This revision is now accepted and ready to land.Sep 22 2021, 9:49 AM

Aren't these very "affine" related (as their name indicates)? The fit isn't clear to me here.
I'm interested in understanding the layering aspect though!

They are more generally applied to ops across multiple dialects (e.g. memref and tensor)
They are similar to AffineExpr and AffineMap in that respect.

IIRC layering issues involve properties such as AffineScope type constraints depending on memref/tensor (because of DimOp) which in turn makes it a circular dependence when trying to write logic based on affine.apply/min/max in memref or tensor.

ftynse accepted this revision.Sep 23 2021, 12:58 AM

Scanned through, looks good to me.

bondhugula added inline comments.Sep 23 2021, 1:04 AM
mlir/include/mlir/Dialect/Arithmetic/IR/Arithmetic.h
41–53

Shouldn't this be in the mlir::arith namespace?

bondhugula added inline comments.Sep 23 2021, 1:08 AM
mlir/lib/Dialect/Arithmetic/IR/ArithmeticCanonicalization.td
14

ArithOps td defs depend on StandardOps? Can we pull what's need from there or move to OpBase.td?

mlir/lib/Dialect/Arithmetic/IR/ArithmeticOps.cpp
12

Likewise. (ArithOps depends on StandardOps?)

Mogball added inline comments.Sep 23 2021, 8:49 AM
mlir/lib/Dialect/Arithmetic/IR/ArithmeticCanonicalization.td
14

The only dependency is ConstantOp. As it turns out, I will need to create arith.const after all, because otherwise std and arith will have a circular dependency...

rriddle added inline comments.Sep 23 2021, 11:11 AM
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticBase.td
26–72

+1.

mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td
147–152

These syntax blocks aren't as useful if the op uses the assemblyFormat field, given that the assembly format will be added to the op documentation. I'd just drop them.

mlir/lib/Dialect/Arithmetic/IR/ArithmeticCanonicalization.td
14

Yeah, I would suggest avoiding a dependency on standard as much as you possibly can.

mlir/lib/Dialect/Arithmetic/IR/ArithmeticOps.cpp
28–37

Only classes should really be in anonymous namespaces, functions should be marked static and at the top level,

Mogball added inline comments.Sep 23 2021, 1:42 PM
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td
147–152

Sounds good. Should I drop/trim some of the really verbose comments too? E.g. "This op requires three operands and one result which must be of the same type. This type can be an integer, a vector whose element type is integer, or a tensor of integers. The custom assembly format of these ops is: ..." etc.

I copied them from Ops.td.

rriddle added inline comments.Sep 23 2021, 1:46 PM
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td
147–152

I'd be fine with dropping anything that is superfluous/a duplication of the documentation that is auto-generated. A lot of this documentation is ancient and predates many automation efforts.

Mogball marked 10 inline comments as done.Sep 28 2021, 9:00 AM
Mogball updated this revision to Diff 375630.Sep 28 2021, 10:04 AM
  • fixing build on CMake
  • clang-tidy errors
  • Fix comments, static functions
  • add arith.const op
Mogball updated this revision to Diff 375665.Sep 28 2021, 12:33 PM
  • add arith.const op

Arcanist is a struggle for me... but I now have the correct diffs shown.

bondhugula added inline comments.Sep 29 2021, 7:47 PM
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td
122

We've so far had llvm.constant, std.constant, mhlo.constant, etc. Prefer naming this constant instead of const for consistency. The op is creating a constant.

129

Nit: floating-point constant

129–130

Nit: uses to form -> forms

Mogball updated this revision to Diff 376101.Sep 29 2021, 10:03 PM
Mogball marked 3 inline comments as done.

rename arith.const -> arith.constant

This revision was automatically updated to reflect the committed changes.
c-rhodes added inline comments.
mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td
95–103

should traits be passed to Arith_CastOp? I noticed some unused warnings for this parameter when providing an update on D109359.

Arcanist is a struggle for me... but I now have the correct diffs shown.

mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td
95–103

Yes, it should. Thanks for catching this. Submitting a fix right now.