Lines Matching refs:conversion
5 illegal operations to those supported by a provided conversion target, via a set
10 The dialect conversion framework consists of the following components:
12 * A [Conversion Target](#conversion-target)
14 * A [Type Converter](#type-conversion) (Optional)
18 When applying a conversion to a set of operations, there are several different
19 conversion modes that may be selected from:
23 - A partial conversion will legalize as many operations to the target as
28 - A partial conversion can be applied via `applyPartialConversion`.
32 - A full conversion legalizes all input operations, and is only successful
33 if all operations are properly legalized to the given conversion target.
34 This ensures that only known operations will exist after the conversion
36 - A full conversion can be applied via `applyFullConversion`.
40 - An analysis conversion will analyze which operations are legalizable to
41 the given conversion target if a conversion were to be applied. This is
42 done by performing a 'partial' conversion and recording which operations
46 - An analysis conversion can be applied via `applyAnalysisConversion`.
50 The conversion target is a formal definition of what is considered to be legal
51 during the conversion process. The final operations generated by the conversion
53 be a success. Depending on the conversion mode, existing operations need not
75 conversion to be successful. This action also allows for selectively
78 An example conversion target is shown below:
153 After the conversion target has been defined, a set of legalization patterns
164 `bar.add` -> `foo.add` even though a direct conversion does not exist. This
170 Along with the general `RewritePattern` classes, the conversion framework
172 relies on interacting with constructs specific to the conversion process, the
173 `ConversionPattern`. For example, the conversion process does not necessarily
175 replacements and erasures, and only applies them when the entire conversion
182 methods, the list of operands that the operation should use after conversion. If
189 conversion infrastructure.
204 The types of the remapped operands provided to a conversion pattern must be of a
214 operands. More information on type conversion is detailed in the
215 [dedicated section](#type-conversion) below.
219 It is sometimes necessary as part of a conversion to convert the set types of
230 main aspects of the `TypeConverter` are conversion and materialization.
232 A `conversion` describes how a given illegal source `Type` should be converted
238 single value of a desired type. An important distinction with a `conversion` is
239 that a `materialization` can produce IR, whereas a `conversion` cannot. These
240 materializations are used by the conversion framework to ensure type safety
241 during the conversion process. There are several types of materializations
247 argument during a [signature conversion](#region-signature-conversion).
253 "legal" during the conversion process, but contains a use of an illegal
254 type. This may happen during a conversion where some operations are
260 the conversion process has finished.
263 remain live after the conversion process is finished.
271 conversion where some operations are converted to those with different
275 [conversion pattern](#conversion-patterns) are not legal for the
276 type conversion provided by the pattern.
279 conversion back to the `source` type, hence source materialization; if an
281 conversion to the `target` type, hence target materialization.
283 As noted above, the conversion process guarantees that the type contract of the
284 IR is preserved during the conversion. This means that the types of value uses
285 will not implicitly change during the conversion process. When the type of a
287 the users of that definition must also be updated during the conversion process.
288 If they aren't, a type conversion must be materialized to ensure that a value of
291 materialization is required, but cannot be performed, the entire conversion
299 /// Register a conversion function. A conversion function defines how a given
300 /// source type should be converted. A conversion function must be convertible
303 /// - This form represents a 1-1 type conversion. It should return nullptr
305 /// converter is allowed to try another conversion function to perform
306 /// the conversion.
308 /// - This form represents a 1-N type conversion. It should return
309 /// `failure` or `llvm::None` to signify a failed conversion. If the new
311 /// existing value are expected to be removed during conversion. If
313 /// conversion function to perform the conversion.
343 /// conversions to an illegal type must persist beyond the main conversion.
363 From the perspective of type conversion, the types of block arguments are a bit
364 special. Throughout the conversion process, blocks may move between regions of
365 different operations. Given this, the conversion of the types for blocks must be
366 done explicitly via a conversion pattern. To convert the types of block
373 custom conversion to the entry block of the region. The types of the entry block
377 be used instead. A signature conversion, `TypeConverter::SignatureConversion`,
384 /// new types are appended to the new signature conversion.
387 /// Append new input types to the signature conversion, this should only be
402 The `TypeConverter` provides several default utilities for signature conversion
408 To debug the execution of the dialect conversion framework,
409 `-debug-only=dialect-conversion` may be used. This command line flag activates
410 LLVM's debug logging infrastructure solely for the conversion framework. The
412 conversion process. This output contains all of the actions performed by the