<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/54255>54255</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [ODS] Eliminate the default value from `arguments` and `results` in the `Op<>` tblgen class?
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          lattner
      </td>
    </tr>
</table>

<pre>
    In an offline discussion, we were talking about whether or not "arguments" and "results" should be specified, even if an operation doesn't have them.  For example, should we have:

```
def FuncOp : FooOp<"func", ...> {
  let arguments = (ins);
  let results = (outs);
  let regions = (region SizedRegion<1>:$body);
}
def AddI32Op : FooOp<"add.i32"> {
  let arguments = (ins I32:$lhs, I32:$rhs);
  let results = (outs I32:$result);
}
def PrintI32Op : FooOp<"print.i32"> {
  let arguments = (ins I32:$value);
  let results = (outs);
}
```

Or go with the more minimal:

```
def FuncOp : FooOp<"func", ...> {
  let regions = (region SizedRegion<1>:$body);
}
def AddI32Op : FooOp<"add.i32"> {
  let arguments = (ins I32:$lhs, I32:$rhs);
  let results = (outs I32:$result);
}
def PrintI32Op : FooOp<"print.i32"> {
  let arguments = (ins I32:$value);
}
```

The MLIR codebase is a mix of the two approaches.

Speaking for myself, I pretty strongly prefer the first approach - where arguments/results are always specified, but where more exotic things like regions are present only when needed.  Although we (the LLVM/MLIR community) don't really have a strong set of principles that guide when a field is defaulted or not, there is a general sense of "don't default primary information about an operation": you want to force some people to think about certain properties of a tblgen declaration.

In the case of arguments/results, almost every op has them, and there are sometimes a *lot* of other stuff in the body of an op definition (e.g. FuncOp has lots of inline C++ stuff).  Having both of these present and at the top of the operation decalration (even when empty) makes it easier for me to understand what are the inputs, attributes, and results of the operation.

Further, it is very conventional for dialects to define their own `FooOp` subclass of `Op` that specifies a dialect.  If some dialect wanted to default these, they could do so in their local world.

What do others think?

-Chris
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJztVsFu4zYQ_Rr5QsRQ5NiODz44yRoNkEWKTdGeKXEksaFIgaTiuF_fN5ScONttsS3QngoItiWRM2_ePL5x6dRxe2-FtMLVtdGWhNKhGkLQzmbFrTgQLk8iSvOsbSNk6YYoDi3FlrxwXlgXRVYU0jdDRzYG_EY0xc88hcGMT0LrBqNESSL0VOlak-Lo9EJW6Dql78nLiKxCOQrIvY6ilS_I3FI3F2KPXPQqu94Q75wCAh4vyha7LL_L8tPnKp-udKuoFvvBVo-9wEJEco99trgFrhpP8cUB5_N5tvgksvXNuEkIQ1G8lYWdd6jpWlvUs8kWH1ZNhZ7WgKFvLmpQ3dui8VY86d9IfUm_AekSELiW4qpEY85jZOu792J2St0vij-WI5Wa60XBFX1fKQJhxnymDczC271vv6_Osx3p5Z9i_tFrG7-Juuc3_xT3izQD_e2OvCH7Sinj56MXjRMHHVsWn-gc9N9pqztp_jWh_a-O_0Qdf934n9Dtzw_3X0TlFJUykNBBSPT-Fe6YtBAPTsi-905WLYX5-eannmSyyBpO1R0DmTpxJnpPMR5FiN7Zxhz5voZ3crha-xDfAooLNlaI7cxM9ydWJT83B3kMHy20HO3YTzqlVxd1heBAEoTRz_QmLY6A3AGBhbMAgm1WWCJFCga7MxGe2rTsqeCR4T08_PwZECZKum6wOrLuYNGjQXuSBoGST8upQhHQFtDFjas07DoAjYyiGbSiMadE4QT3BrtovkR9pKZZwiXFVE6iviGLsWAQ06IbiAoVnJJPWzlRJ_1RaAvmu3GGjGPqfKwk-ezE0Q3iIMFAdNyoCgPJdeCFHJDyQ2buedpfkY9SW2TgMFGjFECQIpYGwACgMnKM_kEJmKfMXiVHyN_oJlcpTefQfIxAYHc9SAxp1qV3GKBxksKIMOqOmJCs2BlmaceRXRrCIQ51jepTUnaGlJRLZ4rgW4kRtJTmzfzkT5wNgVJB2qbBj9N2g2uMhy5DEz_IF1Z0iUTTCQjvGmKQ6Gs6Fsg1nZCzOU6VNNNvzs6zPrWfun6UUSefUZQGCTJoVJJOTurCYBXhaHCKA4uHaeDo2vbDRF-MXkP8FE6EnU7K10A-9GY_eCaN9yAvNJbor5wFOl4MrTEKpaWhCsGAJZGY0mv84zmgmFU-GtQqF2EoIYKQsuJ-fJj0fjql3LUpHBi9r0fBTU-SFiH-MU2ScyJ5OgaMjP_mKIddU4sBwjgwKw7OG_WhuF84L9YmXYRRytlif77k4rb1OszUdqE2i42cRR0NbbPlzePdU7a8E5-MxqiTcaT7hCn5qKi967jId0Gj1vRfb5WfhI0nkxJHNuDhGFrMyXhmElnANBu82bYx9iE59R5Xg4E7lHMYDW6MeTl9XeD4_QqucKtDGLjh--VVsVzO2u0lrYqipGW-prrK89U1UUlytblWqizXG5oZWZIJXCAMwNJBpBBsBsu7md4WeVHki3x9eZ0Xy3xerzd1qa4Wl0u1UYsNZVc5dVKbOeOYO9_M_DZBKocm4KXRIYb3lyhNNzDUlA7x5QBLxQ5oFTY2S6m3CfrvjZybdA">