This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][SPIRV] Towards a consistent assembly scheme: GlobalVariable.
AbandonedPublic

Authored by ergawy on Mar 10 2021, 3:13 AM.

Details

Summary

This commit works towards the effort of defining a consistent assembly
scheme for the spv dialect ops. Currently there are some
inconsistencies in things like: using : and -> to express the return
type of an op.

Following is an initial list of rules proposed by Lei, we will refine
this list as we discuss during reviews:

  • Operands:
    • Use , to separate SSA values in a list
    • Tightly associate type with :directly after the SSA value. : and the type can be omitted if it's clear (i.e., easy to deduce from other types)
    • Use keyword and = as prefix to make the meaning of certain SSA value clear
    • Use [] to mark the range for indexing SSA values. With [], the type for the SSA value that are inserted into can be placed after [].
  • Result: use -> to associate the result type
  • Attributes
    • Attributes defined in the grammar should be placed in [] , preferably directly after the op.
    • Prefer to use unquoted keyword instead of quoted string when possible (For IntEnumAttr it should be possible; for BitEnum it might not be possible to drop the quote given we can have | in the middle.)
  • Use keyword like from/ into/etc. to make the assembly read nicer when possible
  • Exceptions can exist

Diff Detail

Event Timeline

ergawy created this revision.Mar 10 2021, 3:13 AM
ergawy requested review of this revision.Mar 10 2021, 3:13 AM
ergawy added a comment.EditedMar 10 2021, 3:15 AM

@antiagainst, 2 points:

  • I adopted the set of rules you suggested, we can refine them as we discuss on the review.
  • I tried to define GlobalVariable using the declarative format, but it seems that is not possible due to the optional directives: bind and built_in. Let me know if I misunderstood something.
mehdi_amini added inline comments.Mar 10 2021, 9:23 AM
mlir/test/Dialect/SPIRV/Transforms/inlining.mlir
188

Using -> for separating the operands instead of : for the type seems the opposite of everywhere else in MLIR, isn't it?

antiagainst added inline comments.Mar 10 2021, 1:00 PM
mlir/test/Dialect/SPIRV/Transforms/inlining.mlir
188

Oh we still want to use : to associate types with operands. So not trying to replace : with -> everywhere. -> is for specifying result types. (Like how we represent result types in functions, etc.).

One thing that I find misleading w.r.t. types in custom assembly format is that it can be hard to figure out what a type is associated with, if they are all put at the very end, with a single : separating them with operands, especially if we have those types both for operands and results and wanting to omit types for some of them. Like

%0 : = dialect.op %a, %b, %c : typeA, typeB

It's hard to figure out what typeA and typeB are for (%a, %b, %c, or the result)?

For such cases, I'd think using : to immediately attach the type to the operand and use -> to mark result types would be nicer.

WDYT?

mehdi_amini added inline comments.Mar 10 2021, 1:46 PM
mlir/test/Dialect/SPIRV/Transforms/inlining.mlir
188

I'd just like to keep consistency with MLIR, what you're mentioning here could be a reasonable convention but I don't think it has a precedent so far.
What about starting a thread on Discourse about the "good practices and general convention for IR textual syntax"?

antiagainst added inline comments.Mar 10 2021, 2:42 PM
mlir/test/Dialect/SPIRV/Transforms/inlining.mlir
188

Sure will do that.

ergawy planned changes to this revision.Mar 16 2021, 4:41 AM

We will halt working on this until a discussion on a good assembly scheme is discussed with a wider audience.

mravishankar resigned from this revision.May 9 2022, 3:35 PM
ergawy abandoned this revision.Aug 26 2022, 6:58 AM