Python bindings now attempt to perform result type inference, so we no
longer have to. This is great in general, but we need to complicate
our logic to support the NamedValueOpView functionality.
In cases where all operands are known a-priori, we defer to
ODS-generated result type inference when possible. In these cases, the
result type is removed from user-facing APIs, and may require
downstream updates to remove the now-redundant result type at call
sites.
In cases where not all operands are known and we are building
backedges, we take care to ensure the ODS-generated result type
inference is used. Ops that may build backedges and do not have result
type inference now pass a special flag needs_result_type.
Closes https://github.com/llvm/circt/issues/1995.
This adds a create classmethod to the variadic and other Comb ops,
rounding out the Python bindings sugar for the Comb dialect.
Additionally, this removes the kwargs from the non-variadic Comb ops'
create classmethods. This presents the same API as the variadic ops
for the common case where all the operands are known at the time the
op is constructed.
Under the hood, non-variadic ops still use the NamedValueOpView to
continue supporting the less common case of constructing the operands
incrementally. Incremental construction is simply not possible for the
variadic ops, since we need to know how many operands to build at
construction time.
- Creating new frontends top level directory which contains frontends which are optionally included.
- Moving @module and @Generator into PyCDE frontend.
- Keeping connect in the bindings since it's used in the bindings tests.
- Fixing the integration tests.
Closes#1179.
The comparators all return an i1, so we simply don't need a result
type there. The binary ops all have the SameOperandsAndResultType
trait, so we can check the operand types and infer the result type.
Adam Izraelevitz