In go/ast, we use ast.Expr and ast.Stmt to represent when an ast.Node is known to be an expression or statement, respectively.

Within cmd/compile, we have analogous ir.Expr and ir.Stmt interface types, but for historical reasons most code still uses ir.Node. This issue lays out a plan for how to migrate the compiler to use them. (Having started a few attempts at this, it's clearly not something that can gracefully land in a single CL.)

1. Introduce new ir.ExprNode and ir.StmtNode types. Normally, these will be type aliases to ir.Node; but if the strict-ir build tag is set, then they'll be aliases to ir.Expr and ir.Stmt, respectively, instead.
2. Add a unit test (e.g., cmd/compile/internal/ir.TestStrictIR) that simply uses go/types to check that a (initially empty) list of packages all still type check successfully with the strict-ir build tag set.
3. One package at a time, replace as many uses of ir.Node with ir.ExprNode or ir.StmtNode as possible (and refactoring code as needed), and then add the package to the unit test from step 2 to prevent backsliding.
4. Once all cmd/compile packages have been transitioned, we change ir.ExprNode and ir.StmtNode to be aliases to ir.Expr and ir.Stmt unconditionally (i.e., make strict-ir the default/only mode), and remove TestStrictIR too.
5. Global rewrite CL removing ir.ExprNode and ir.StmtNode and replacing all uses with ir.Expr and ir.Stmt. (This could be split into 2 or more steps if we're concerned about conflicts with in-flight CLs; but I think as long as we give heads up before landing the CL, it should be fine.)

I don't think this is pressing work, but wanted to lay out a plan and start getting buy-in from the rest of the compiler team before embarking upon it.

Two possible cons to this plan to note:

1. Interface-to-interface type conversions (e.g., Expr->Node or Stmt->Node) require a runtime conversion to compute the itab, so it's possible this ends up slowing down some code paths. This is something worth measuring between steps 3 and 4. (Any ideas on how to measure the possible impact here before doing all the work would be welcome.)
2. Because we can't use generics in the compiler, we'll probably have to duplicate some []ir.Node code paths to also operate on []ir.Expr and []ir.Stmt.

It's worth noting though that both of these cons apply to go/ast already, and I've not heard them raised before. But then Go 1 compatibility also precludes any work that could address these issues.