f431d3878a
The current behavior is conveniently allowing to iterate on the regions of an operation implicitly by exposing an operation as Iterable. However this is also error prone and code that may intend to iterate on the results or the operands could end up "working" apparently instead of throwing a runtime error. The lack of static type checking in Python contributes to the ambiguity here, it seems safer to not do this and require and explicit qualification to iterate (`op.results`, `op.regions`, ...). Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D111697
27 lines
680 B
Python
27 lines
680 B
Python
# RUN: %PYTHON %s | FileCheck %s
|
|
|
|
from mlir.ir import *
|
|
import mlir.dialects.builtin as builtin
|
|
import mlir.dialects.math as mlir_math
|
|
|
|
def run(f):
|
|
print("\nTEST:", f.__name__)
|
|
f()
|
|
|
|
# CHECK-LABEL: TEST: testMathOps
|
|
@run
|
|
def testMathOps():
|
|
with Context() as ctx, Location.unknown():
|
|
module = Module.create()
|
|
with InsertionPoint(module.body):
|
|
@builtin.FuncOp.from_py_func(F32Type.get())
|
|
def emit_sqrt(arg):
|
|
return mlir_math.SqrtOp(arg)
|
|
|
|
# CHECK-LABEL: func @emit_sqrt(
|
|
# CHECK-SAME: %[[ARG:.*]]: f32) -> f32 {
|
|
# CHECK: math.sqrt %[[ARG]] : f32
|
|
# CHECK: return
|
|
# CHECK: }
|
|
print(module)
|