[Relay][RFC] Relay IR Text Format by joshpoll · Pull Request #1781 · apache/tvm

joshpoll · 2018-09-28T02:57:34Z

[RFC]: Relay IR Text Format

Please comment on syntax in #1782.

This PR introduces the Relay IR text format. It is intended to be used similarly to LLVM's text format. For example, a text format makes it easier to debug Relay programs and optimization passes as well as serve as a target language for machine learning front ends.

This PR will include

An ANTLR grammar for the Relay IR text format.
A parser that uses the grammar to produce a Relay AST.
A pretty printer that prints a Relay AST in text format. Follow-up PR.

The syntax is heavily inspired by LLVM, Rust, and ReasonML.

Note: The ANTLR grammar accepts some programs that aren't valid Relay programs in order to have better error messages at parse time.

tqchen · 2018-09-28T03:48:23Z

CC @dmlc/tvm-team

tqchen · 2018-09-28T03:50:32Z

The main point we want to address is how to print the code in graph form (without all the lets). This is important because most people construct their net in this way. As an example, we could have

add(%x, add(%y, %z))

but a preferred way of printing it should be

%1 = add(%y, %z)
%2 = add(%x, %1)

nhynes · 2018-09-28T04:06:26Z

how to print the code in graph form

Out of curiosity, what's wrong with lets? The line per assign is easy to debug and parse. If a user wanted to visualize the graph, the Relay IR can be lowered to graphviz or revered in Tensorboard. Since everything has a unique name, it'll be easy to jump back and forth.

tqchen · 2018-09-28T04:09:27Z

I just feel there is a tension that user still starts with the old habit of constructing things via DSL(graph form), which makes them cluttered in that case. The printer need to print out the program faithfully still in this case without having to generate a long line of nested calls

tqchen · 2018-09-28T04:19:11Z

Let us move the discussion to the corresponding RFC issue. @joshpoll can you cross post the proposal there and use the PR to mainly comment on implementation details?

yuruofeifei · 2018-09-28T05:49:36Z

+
+// non-negative ints
+// INT: '0' | [1-9] DIGIT* ; // no leading zeros
+INT: DIGIT+ ;


seems it will still accept leading zeros.

We now intentionally parse accept leading zeros to be more forgiving. I'll delete the old version.

yuruofeifei · 2018-09-28T05:49:38Z

+// TODO: is this really the desired outline? if there are defns should there be an expression at the end?
+prog: option* (expr | defn+) EOF ;
+
+option: 'set' ident BOOL_LIT ;


what is option's purpose? Why it is tied to bool literal only?

These are intended to be boolean compiler options not none/some options. I think @jroesch can speak more directly to their purpose.

In the previous iteration our design goal was to enable the text format to be able to set pragmas/options for the program.

yuruofeifei · 2018-09-28T05:49:40Z

+  : '(' expr ')'                  # parens
+  | '-' expr                              # neg
+  | expr op=('*'|'/') expr                # binOp
+  | expr op=('+'|'-') expr                # binOp


do we need explicit operator associativity?

Yes. The ANTLR grammar is used to automatically generate the lexer and the bulk of the parser, so it's important to encode associativity here.

yuruofeifei · 2018-09-28T05:49:42Z

+  | expr op=('=='|'!=') expr              # binOp
+
+  // function definition and application
+  | expr '(' (expr (',' expr)*)? ')'      # call


I feel like we need the function name as an indent instead of expr since expr will accept too much.

I kind of agree; however, that becomes restrictive if we want to use curried functions. It's possible to restrict what expressions can be used in calls in the parser itself.

If we want to control the form of the program we should not do it in the parser as it makes the parser overly restrictive and forces semantic information into the parser instead of later analysis phases.

It also disallows programs which are semantically equivalent.

For example:

let x = f(x, y, z); x(z, y)

Instead of:

f(x, y, z)(z, y)

Even if it looks ugly we should let people generate the text format how they see fit imo.

For example a simple compiler targeting Relay might generate code like:

(fn (...) { ... })(x, y, z)

yuruofeifei · 2018-09-28T05:49:43Z

+  | 'if' expr body 'else' body            # ifElse
+
+  // sequencingg
+  | 'let' MUT? ident (':' type_)? '=' expr ';' expr  # let


what does expr ';' expr mean here?

Relay doesn't have statements, only expressions. Thus let %x = 1; is not valid Relay, because it doesn't have a value. let expressions must always contain an identity, an assignment, and a body that might use that assignment (which is the value of the let expression). For example,

let %x = 1; %x

is valid Relay and evaluates to 1.

This is similar to the syntax used by ReasonML, which is a version of OCaml made to look like JavaScript.

yuruofeifei · 2018-09-28T05:49:45Z

+  | ident                         # identExpr
+  | scalar                        # scalarExpr
+  | expr '.' INT                  # project
+  | 'debug'                       # debug


I think expr should also accept body ?

This is a good idea, and I'll look into it. It's not immediately clear what the semantics of the body should be, since Relay has no concept of it.

yuruofeifei · 2018-09-28T05:49:47Z

+fun:  'fn'        paramList '=>' type_? body ;
+defn: 'def' ident paramList '=>' type_? body ;
+
+paramList: '(' param (',' param)* ')' ;


Seems fun does not accept zero parameters.

yuruofeifei · 2018-09-28T05:49:48Z

+// bool
+
+baseType
+  : 'int(' INT ',' INT ')' # intType


Int can be any arbitrary number, is that expected?

INT is really a natural number, which is what we want for projection and the inputs here, which represent bits and lanes. Maybe I should change the name to reflect that.

I think the type checker should enforce constraints on this, it will yield a better error.

What do you think about adding a type-level function syntax and moving this sort of parsing into the python parser?

MarisaKirisame · 2018-09-28T06:08:54Z

The main point we want to address is how to print the code in graph form (without all the lets). This is important because most people construct their net in this way. As an example, we could have
add(%x, add(%y, %z))
but a preferred way of printing it should be
%1 = add(%y, %z)
%2 = add(%x, %1)

I am a bit confused. doesnt the lower code has two let?

sergei-mironov · 2018-09-28T11:12:56Z

+
+type_
+  : '(' type_ ')'                           # parensType
+  | type_ op=('*'|'/') type_                # binOpType


May I ask to provide short examples in comments?

I think examples might be better suited to docs, but I'm open to this.

sergei-mironov · 2018-09-28T11:21:33Z

+
+// a program is a list of options followed by either an expression or a list of definitions
+// TODO: is this really the desired outline? if there are defns should there be an expression at the end?
+prog: option* (expr | defn+) EOF ;


+1 to expr at the end. Why don't we want local defns?

defns are global function definitions. The idiomatic way to do local definitions is

let foo = fn (x, y) => { ... }; ...

It's difficult to see a better syntactic way to express them, but I'm open to ideas.

sergei-mironov · 2018-09-28T11:30:24Z

+LE: '<=' ;
+GE: '>=' ;
+EQ: '==' ;
+NE: '!=' ;


Should we define operators as a sequence of "+-*/%..." symbols plus associativity? This would probably reduce the size of grammar.

The purpose of these lines is to provide symbols that represent these pieces of syntax in the rest of the parser. I'm considering splitting the lexer and parser files as this would probably improve readability. This is idiomatic ANTLR as far as I can tell. A wealth of example grammars can be found here.

sergei-mironov · 2018-09-28T11:34:08Z

+  // sugar for let _ = WriteRef(ident, expr); expr
+  | ident '=' expr ';' expr               # writeRef
+
+  | ident                         # identExpr


Should global expressions consist of global idents only? If so, how to express it here?

In the rest of the parser, we restrict the kinds of idents that can appear in certain positions. The ANTLR grammar is more lenient, though, because it allows us to produce better error messages when someone accidentally uses the wrong type of ident.

joshpoll · 2018-10-05T23:56:40Z

grammar/py2 and grammar/py3 are build artifacts. They are included to avoid Java as a dependency.

tqchen · 2018-10-06T02:09:42Z

Let us avoid include building artifacts for now, as long as the parser is a separate dep it is fine. Later we can to do a binary release of artifact where the build can depend on

MarisaKirisame · 2018-10-15T00:23:57Z

  void VisitType_(const IncompleteTypeNode* bt1, const Type& t2) final {
    if (const IncompleteTypeNode* bt2 = t2.as<IncompleteTypeNode>()) {
-      equal = equal && bt1 == bt2;
+      equal = equal && bt1->kind == bt2->kind;


can you have this in a seprate 1-line pr? I need it to restore anf testing

tqchen · 2018-12-02T18:35:29Z

Thanks, @jroesch @joshpoll @grwlf @yuruofeifei @junrushao1994 @MarisaKirisame , this is now merged

joshpoll mentioned this pull request Sep 28, 2018

[RFC] Relay IR Text Format #1782

Closed

yuruofeifei reviewed Sep 28, 2018

View reviewed changes

sergei-mironov reviewed Sep 28, 2018

View reviewed changes

joshpoll force-pushed the relay-text-format branch 3 times, most recently from e6951dc to faa79bc Compare October 5, 2018 23:55

joshpoll mentioned this pull request Oct 6, 2018

[RELAY][OP] Relay Operator Sprint #1799

Closed

66 tasks

joshpoll force-pushed the relay-text-format branch 4 times, most recently from e824e2f to e75de2c Compare October 13, 2018 22:47

MarisaKirisame reviewed Oct 15, 2018

View reviewed changes

joshpoll added 20 commits November 30, 2018 20:11

complete parser testing compatibility and expose fromtext

7d956fb

fix bad imports

a396cf7

ImportError -> Exception

e04dfa5

linting

3fd20b1

linting

9f03684

linting

98e44c5

ci bump

ac74b91

exit earlier

fe8a7a6

dependencies

bac7c19

delete separate script

fcd220b

failing test. should fail ci

0cf7594

simplify failing test. rework import

30bbbfc

switch USE_ANTLR from cpu to gpu

4eaca59

rebase

3199d1e

fix ci (please)

081a907

source /etc/profile to add JAVA_HOME

f837861

revert install_java change. source /etc/profile during make function

7eefbf3

enable antlr on gpu

f3abc5d

trigger parser tests

3e2244f

revert Dockerfile to master. remove parser tests from this pr

ce72502

joshpoll force-pushed the relay-text-format branch from 7642084 to ce72502 Compare December 1, 2018 04:12

joshpoll added 3 commits November 30, 2018 20:13

revert source

f092434

use ENV

5653528

modify how ANTLR runs in cmake

533972b

tqchen merged commit d3bc59d into apache:master Dec 2, 2018

FrozenGene pushed a commit to FrozenGene/tvm that referenced this pull request Dec 27, 2018

[Relay][RFC] Relay IR Text Format (apache#1781)

29b2e01

ZihengJiang mentioned this pull request Feb 1, 2019

TVM 0.5 Release Note #2448

Closed

wweic pushed a commit to neo-ai/tvm that referenced this pull request Feb 20, 2019

[Relay][RFC] Relay IR Text Format (apache#1781)

4346e16

wweic pushed a commit to neo-ai/tvm that referenced this pull request Feb 20, 2019

[Relay][RFC] Relay IR Text Format (apache#1781)

0d4f6f4

Conversation

joshpoll commented Sep 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

[RFC]: Relay IR Text Format

Uh oh!

tqchen commented Sep 28, 2018

Uh oh!

tqchen commented Sep 28, 2018

Uh oh!

nhynes commented Sep 28, 2018

Uh oh!

tqchen commented Sep 28, 2018

Uh oh!

tqchen commented Sep 28, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshpoll Sep 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshpoll Sep 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MarisaKirisame commented Sep 28, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshpoll commented Oct 5, 2018

Uh oh!

tqchen commented Oct 6, 2018

Uh oh!

Choose a reason for hiding this comment

joshpoll commented Sep 28, 2018 •

edited

Loading

joshpoll Sep 28, 2018 •

edited

Loading

joshpoll Sep 28, 2018 •

edited

Loading