[all-commits] [llvm/llvm-project] 27c6d5: [mlir][python] generate value builders (#68308)

[Maksim Levental via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 27c6d55cae74125b6381a647533090a72930ecda
      https://github.com/llvm/llvm-project/commit/27c6d55cae74125b6381a647533090a72930ecda
  Author: Maksim Levental <maksim.levental at gmail.com>
  Date:   2023-10-09 (Mon, 09 Oct 2023)

  Changed paths:
    M mlir/python/mlir/dialects/_ods_common.py
    M mlir/python/mlir/dialects/_scf_ops_ext.py
    M mlir/python/mlir/dialects/scf.py
    M mlir/test/mlir-tblgen/op-python-bindings.td
    M mlir/test/python/dialects/scf.py
    M mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp

  Log Message:
  -----------
  [mlir][python] generate value builders (#68308)

This PR adds the additional generation of what I'm calling "value
builders" (a term I'm not married to) that look like this:

```python
def empty(sizes, element_type, *, loc=None, ip=None):
    return get_result_or_results(tensor.EmptyOp(sizes=sizes, element_type=element_type, loc=loc, ip=ip))
```

which instantiates a `tensor.EmptyOp` and then immediately grabs the
result (`OpResult`) and then returns that *instead of a handle to the
op*.

What's the point of adding these when `EmptyOp.result` already exists?
My claim/feeling/intuition is that eDSL users are more comfortable with
a value centric programming model (i.e., passing values as operands) as
opposed to an operator instantiation programming model. Thus this change
enables (or at least goes towards) the bindings supporting such a user
and use case. For example,

```python
i32 = IntegerType.get_signless(32)
...
ten1 = tensor.empty((10, 10), i32)
ten2 = tensor.empty((10, 10), i32)
ten3 = arith.addi(ten1, ten2)
```

Note, in order to present a "pythonic" API and enable "pythonic" eDSLs,
the generated identifiers (op names and operand names) are snake case
instead of camel case and thus `llvm::convertToSnakeFromCamelCase`
needed a small fix. Thus this PR is stacked on top of
https://github.com/llvm/llvm-project/pull/68375.

In addition, as a kind of victory lap, this PR adds a "rangefor" that
looks and acts exactly like python's `range` but emits `scf.for`.