Lines Matching refs:be
10 valuable constraints that could be captured even without full knowledge of the
16 inference. The return type can often be deduced from the deduced return shape
18 inference for tensor types can be implemented with `InferShapedTypeOpInterface`.
25 Initially the shape inference will be declaratively specified using:
28 constraining the input type to be tensor/vector elements or that the
29 elemental type be of a specific type (e.g., output of computing the size
47 explicit check will be removed and made part of Op verification instead.
57 focus will be on shape functions that describe shape functions could be used in
63 of the output shape). As shown in the shaped container type, shape will be one
75 An argument could be made that these are metadata function instead of shape
93 operands. If the constraints are not satisfied or cannot be determined if
94 satisfied statically, then a runtime check/assertion could be generated.
97 should be usable by both the compiler and runtime.
98 * Shape error functions should be easy to understand, at least what
100 function error messages should be configurable by the author of the
101 shape function (e.g., the author would be able to give the semantic
103 * The static analysis may be used to eliminate run-time checks that are
106 [Inlining shape checking](#inline)) be elided.
114 description should be consumable by either.
115 * Shape function description should not be constrained by either runtime
117 is, these two type systems differ and both should be supported, but the
118 intersection of the two should not be required. As a particular example,
126 * This may not strictly be a requirement, but a way to handle the former:
127 a declarative specification could be reused by both while avoiding a
142 * Shape functions should be cheap to invoke on each kernel launch.
143 * Shape function can be dictated by arguments (operands, attributes and regions)
144 only (e.g., same operands as the corresponding operation could be
148 * The function should be invocable before/while constructing an op (e.g.,
151 * Shape functions should be pure functions.
157 determining the shape & then post to be able to actually consume the
160 * The shape function operation dialect should be interoperable with non-shape function dialect op…
162 * There may be a common set of operations that satisfy most uses (e.g., merge,
164 attributes such as padding etc.) that will be discovered and could cover
165 a large percentage of the use cases. Among these there will be some
166 which carry extra semantic info that could be used for symbolic
173 computations could still be performed. This means that the computations
174 performed statically may or may not be supported by an arbitrary solver,
175 but would still be allowed.
177 * The shape function should be expandable such that symbolic equality and
178 upper bound constraints (say) could be represented and may be propagated by
190 * Reporting errors should be optional. E.g., The same function
191 may be used as to query validity without reporting an error.
196 * While the functions should be readable, it doesn't carry the
202 obtain from them are general enough that they would be useful for
206 be evaluated independently of this proposal and with concrete benefit
208 1. Describe the approach whereby error messages will be generated;
209 * While the shape functions will be able to emit errors optionally, it
210 will be possible to dictate when they emit an error. This enables
218 potentially be built as part of some higher order analysis that reuse
221 * More involved computations can be performed with statically known shapes
222 than what can be sensibly analyzed with unknown/symbolic variables.
228 Shape functions should be lowerable to runtime checks for validity. E.g. verify
236 patterns) and so could be delayed until later (with another round of
247 function from those. Where not, an explicit shape function should be specified
253 This could be done in future! The extracted shape function would use the shape
257 #### How/in what language will the shape functions be authored?
273 shaped inputs be marked specially? E.g., read from file.
279 Shape functions are determined by attributes and could be arbitrarily
283 type and shape]) and so these should be easy to specify. Algebraic relationships
284 would also be common (e.g., a concat of `[n,m]` and `[n,m]` matrix along axis 0
290 function, the reference implementation of the operation will be used to derive