[PATCH] D79146: [MLIR][docs] Update tutorial language around Op and Operation* and 'opaque'

Stephen Neuendorffer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 29 20:33:26 PDT 2020


stephenneuendorffer marked 4 inline comments as done.
stephenneuendorffer added a comment.

Thanks for reviewing!



================
Comment at: mlir/docs/Interfaces.md:3
 
-MLIR is generic and very extensible; it allows for opaquely representing many
-different dialects that have their own operations, attributes, types, and so on.
-This allows for dialects to be very expressive in their semantics and for MLIR
-to capture many different levels of abstraction. The downside to this is that
-transformations and analyses must be extremely conservative about the operations
-that they encounter, and must special-case the different dialects that they
-support. To combat this, MLIR provides the concept of `interfaces`.
+MLIR is generic and very extensible; it generically represents many
+different dialects that have their own operations, attributes, types,
----------------
rriddle wrote:
> Maybe just `it allows for representing` so we don't have generic and generically right after each other?
I was trying to turn this into active voice in the process, but I agree it's still awkward.


================
Comment at: mlir/docs/OpDefinitions.md:352
+[Operation interfaces](Interfaces.md#operation-interfaces) are a
+mechanism allowing operations to expose method calls, without the
+caller needing to know the exact operation type. Operation interfaces
----------------
rriddle wrote:
> nit: allowing -> by which operations can expose?
I think it reads better with the simpler construction.  Maybe even "operation interfaces allow operations to expose..."


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79146/new/

https://reviews.llvm.org/D79146





More information about the llvm-commits mailing list