caio/clang-p2996
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[mlir][doc] Fix links and references in top level docs directory

Browse Source 
This is the fourth and final patch in a series of patches fixing markdown links and references inside the mlir documentation. This patch combined with the other three should fix almost every broken link on mlir.llvm.org as far as I can tell.

This patch in particular addresses all Markdown files in the top level docs directory.

Differential Revision: https://reviews.llvm.org/D103032
This commit is contained in:
Markus Böck
2021-05-24 18:40:39 +02:00
parent 694068d0db
commit d35bd98651
19 changed files with 60 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
mlir/docs/Bufferization.md
View File

@@ -38,7 +38,7 @@ of:
1. Buffer optimizations such as `buffer-hoisting`, `buffer-loop-hoisting`, and
`promote-buffers-to-stack`, which do optimizations that are only exposed
after bufferization.
1. Finally, running the [buffer deallocation](BufferDeallocation.md) pass.
1. Finally, running the [buffer deallocation](BufferDeallocationInternals.md) pass.
After buffer deallocation has been completed, the program will be quite
difficult to transform due to the presence of the deallocation ops. Thus, other

2
mlir/docs/Canonicalization.md
View File

@@ -106,7 +106,7 @@ defining operation rewrites.
The `fold` mechanism is an intentionally limited, but powerful mechanism that
allows for applying canonicalizations in many places throughout the compiler.
For example, outside of the canonicalizer pass, `fold` is used within the
[dialect conversion infrastructure](#DialectConversion.md) as a legalization
[dialect conversion infrastructure](DialectConversion.md) as a legalization
mechanism, and can be invoked directly anywhere with an `OpBuilder` via
`OpBuilder::createOrFold`.

6
mlir/docs/ConversionToLLVMDialect.md
View File

@@ -1,7 +1,7 @@
# Conversion to the LLVM Dialect
Conversion from several dialects that rely on
[built-in types](LangRef.md#builtin-types) to the
[built-in types](LangRef.md/#builtin-types) to the
[LLVM Dialect](Dialects/LLVM.md) is expected to be performed through the
[Dialect Conversion](DialectConversion.md) infrastructure.
@@ -36,7 +36,7 @@ following conversions are currently implemented:
Index type is converted to an LLVM dialect integer type with bitwidth equal to
the bitwidth of the pointer size as specified by the
[data layout](Dialects/LLVM.md#data-layout-and-triple) of the closest module.
[data layout](Dialects/LLVM.md/#data-layout-and-triple) of the closest module.
For example, on x86-64 CPUs it converts to `i64`. This behavior can be
overridden by the type converter configuration, which is often exposed as a pass
option by conversion passes.
@@ -63,7 +63,7 @@ information must be present at runtime in the LLVM dialect equivalent type.
In practice, the conversion supports two conventions:
- the default convention for memrefs in the
**[strided form](LangRef.md#strided-memref)**;
**[strided form](Dialects/Builtin.md/#strided-memref)**;
- a "bare pointer" conversion for statically-shaped memrefs with default
layout.

2
mlir/docs/DataLayout.md
View File

@@ -97,7 +97,7 @@ Extensibility of the data layout modeling is provided through a set of MLIR
### Data Layout Specifications
Data layout specification is an [attribute](LangRef.md#attributes) that is
Data layout specification is an [attribute](LangRef.md/#attributes) that is
conceptually a collection of key-value pairs called data layout specification
_entries_. Data layout specification attributes implement the
`DataLayoutSpecInterface`, described below. Each entry is itself an attribute

2
mlir/docs/DebugActions.md
View File

@@ -117,7 +117,7 @@ bool shouldApplyPattern(Operation *currentOp, const Pattern &currentPattern) {
## Debug Action Handler
A debug action handler provides the internal implementation for the various
action related queries within the [`DebugActionManager`](debug-action-manager).
action related queries within the [`DebugActionManager`](#debug-action-manager).
Action handlers allow for external entities to control and inject external
information into the compiler. Handlers can be registered with the
`DebugActionManager` using `registerActionHandler`. There are two types of

4
mlir/docs/DeclarativeRewrites.md
View File

@@ -51,7 +51,7 @@ features:
* Matching multi-result ops in nested patterns.
* Matching and generating variadic operand/result ops in nested patterns.
* Packing and unpacking variadic operands/results during generation.
* [`NativeCodeCall`](#native-code-call-transforming-the-generated-op)
* [`NativeCodeCall`](#nativecodecall-transforming-the-generated-op)
returning more than one results.
## Rule Definition
@@ -90,7 +90,7 @@ Each pattern is specified as a TableGen `dag` object with the syntax of
`(operator arg0, arg1, ...)`.
`operator` is typically an MLIR op, but it can also be other
[directives](#special-directives). `argN` is for matching (if used in source
[directives](#rewrite-directives). `argN` is for matching (if used in source
pattern) or generating (if used in result pattern) the `N`-th argument for
`operator`. If the `operator` is some MLIR operation, it means the `N`-th
argument as specified in the `arguments` list of the op's definition.

2
mlir/docs/Diagnostics.md
View File

@@ -60,7 +60,7 @@ InFlightDiagnostic emit(Location loc, DiagnosticSeverity severity);
```
Using the `DiagnosticEngine`, though, is generally not the preferred way to emit
diagnostics in MLIR. [`operation`](LangRef.md#operations) provides utility
diagnostics in MLIR. [`operation`](LangRef.md/#operations) provides utility
methods for emitting diagnostics:
```c++

10
mlir/docs/Interfaces.md
View File

@@ -252,7 +252,7 @@ Note: Before reading this section, the reader should have some familiarity with
the concepts described in the
[`Operation Definition Specification`](OpDefinitions.md) documentation.
As detailed above, [Interfaces](attribute-operation-type-interfaces) allow for
As detailed above, [Interfaces](#attributeoperationtype-interfaces) allow for
attributes, operations, and types to expose method calls without requiring that
the caller know the specific derived type. The downside to this infrastructure,
is that it requires a bit of boiler plate to connect all of the pieces together.
@@ -554,7 +554,7 @@ interface section goes as follows:
- RegionKind::Graph - represents a graph region without control flow
semantics
- RegionKind::SSACFG - represents an
[SSA-style control flow](LangRef.md#modeling-control-flow) region
[SSA-style control flow](LangRef.md/#control-flow-and-ssacfg-regions) region
with basic blocks and reachability
- `hasSSADominance(unsigned index)` - Return true if the region with the
given index inside this operation requires dominance.
@@ -562,11 +562,11 @@ interface section goes as follows:
##### SymbolInterfaces
* `SymbolOpInterface` - Used to represent
[`Symbol`](SymbolsAndSymbolTables.md#symbol) operations which reside
[`Symbol`](SymbolsAndSymbolTables.md/#symbol) operations which reside
immediately within a region that defines a
[`SymbolTable`](SymbolsAndSymbolTables.md#symbol-table).
[`SymbolTable`](SymbolsAndSymbolTables.md/#symbol-table).
* `SymbolUserOpInterface` - Used to represent operations that reference
[`Symbol`](SymbolsAndSymbolTables.md#symbol) operations. This provides the
[`Symbol`](SymbolsAndSymbolTables.md/#symbol) operations. This provides the
ability to perform safe and efficient verification of symbol uses, as well
as additional functionality.

6
mlir/docs/LLVMDialectMemRefConvention.md
View File

@@ -1,9 +1,9 @@
# Built-in Function and MemRef Calling Convention
This documents describes the calling convention implemented in the conversion of
built-in [function operation](LangRef.md#functions), standard
[`call`](Dialects/Standard.md#stdcall-callop) operations and the handling of
[`memref`](LangRef.md#memref-type) type equivalents in the
built-in [function operation](Dialects/Builtin.md/#func-mlirfuncop), standard
[`call`](Dialects/Standard.md/#stdcall-callop) operations and the handling of
[`memref`](Dialects/Builtin.md#memreftype) type equivalents in the
[LLVM dialect](Dialects/LLVM.md). The conversion assumes the _default_
convention was used when converting
[built-in to the LLVM dialect types](ConversionToLLVMDialect.md).

18
mlir/docs/LangRef.md
View File

@@ -34,7 +34,7 @@ system](#type-system). [Operations](#operations) are contained in
[Blocks](#blocks) and Blocks are contained in [Regions](#regions). Operations
are also ordered within their containing block and Blocks are ordered in their
containing region, although this order may or may not be semantically
meaningful in a given [kind of region](Interfaces.md#regionkindinterfaces)).
meaningful in a given [kind of region](Interfaces.md/#regionkindinterfaces)).
Operations may also contain regions, enabling hierarchical structures to be
represented.
@@ -56,7 +56,7 @@ allowing operation semantics to be described abstractly using
to operate on operations more generically. Traits often describe verification
constraints on valid IR, enabling complex invariants to be captured and
checked. (see [Op vs
Operation](Tutorials/Toy/Ch-2/#op-vs-operation-using-mlir-operations))
Operation](Tutorials/Toy/Ch-2.md/#op-vs-operation-using-mlir-operations))
One obvious application of MLIR is to represent an
[SSA-based](https://en.wikipedia.org/wiki/Static_single_assignment_form) IR,
@@ -223,12 +223,12 @@ scope of values in a region with [SSA control flow
semantics](#control-flow-and-ssacfg-regions) is constrained according
to the standard definition of [SSA
dominance](https://en.wikipedia.org/wiki/Dominator_\(graph_theory\)). Another
example is the [IsolatedFromAbove trait](Traits.md#isolatedfromabove),
example is the [IsolatedFromAbove trait](Traits.md/#isolatedfromabove),
which restricts directly accessing values defined in containing
regions.
Function identifiers and mapping identifiers are associated with
[Symbols](SymbolsAndSymbolTables) and have scoping rules dependent on
[Symbols](SymbolsAndSymbolTables.md) and have scoping rules dependent on
symbol attributes.
## Dialects
@@ -411,7 +411,7 @@ operations" SSA IRs (like LLVM). For example, the [parallel copy
semantics](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.524.5461&rep=rep1&type=pdf)
of SSA is immediately apparent, and function arguments are no longer a
special case: they become arguments to the entry block [[more
rationale](Rationale/Rationale.md#block-arguments-vs-phi-nodes)]. Blocks
rationale](Rationale/Rationale.md/#block-arguments-vs-phi-nodes)]. Blocks
are also a fundamental concept that cannot be represented by
operations because values defined in an operation cannot be accessed
outside the operation.
@@ -427,7 +427,7 @@ regions: [SSACFG regions](#control-flow-and-ssacfg-regions), which describe
control flow between blocks, and [Graph regions](#graph-regions), which do not
require control flow between block. The kinds of regions within an operation
are described using the
[RegionKindInterface](Interfaces.md#regionkindinterfaces).
[RegionKindInterface](Interfaces.md/#regionkindinterfaces).
Regions do not have a name or an address, only the blocks contained in a
region do. Regions must be contained within operations and have no type or
@@ -459,7 +459,7 @@ don't escape to the enclosing region, if any. By default, operations inside a
region can reference values defined outside of the region whenever it would
have been legal for operands of the enclosing operation to reference those
values, but this can be restricted using traits, such as
[OpTrait::IsolatedFromAbove](Traits.md#isolatedfromabove), or a custom
[OpTrait::IsolatedFromAbove](Traits.md/#isolatedfromabove), or a custom
verifier.
Example:
@@ -483,7 +483,7 @@ defined in a region can never be used outside of the region.
### Control Flow and SSACFG Regions
In MLIR, control flow semantics of a region is indicated by
[RegionKind::SSACFG](Interfaces.md#regionkindinterfaces). Informally, these
[RegionKind::SSACFG](Interfaces.md/#regionkindinterfaces). Informally, these
regions support semantics where operations in a region 'execute
sequentially'. Before an operation executes, its operands have well-defined
values. After an operation executes, the operands have the same values and
@@ -569,7 +569,7 @@ directly used values remain live.
### Graph Regions
In MLIR, graph-like semantics in a region is indicated by
[RegionKind::Graph](Interfaces.md#regionkindinterfaces). Graph regions are
[RegionKind::Graph](Interfaces.md/#regionkindinterfaces). Graph regions are
appropriate for concurrent semantics without control flow, or for modeling
generic directed graph data structures. Graph regions are appropriate for
representing cyclic relationships between coupled values where there is no

12
mlir/docs/OpDefinitions.md
View File

@@ -341,7 +341,7 @@ currently only be specified as the last successor in the successor list.
Traits are operation properties that affect syntax or semantics. MLIR C++ models
various traits in the `mlir::OpTrait` namespace.
Both operation traits, [interfaces](Interfaces.md#utilizing-the-ods-framework),
Both operation traits, [interfaces](Interfaces.md/#utilizing-the-ods-framework),
and constraints involving multiple operands/attributes/results are provided as
the second template parameter to the `Op` class. They should be deriving from
the `OpTrait` class. See [Constraints](#constraints) for more information.
@@ -605,7 +605,7 @@ The available directives are as follows:
* `functional-type` ( inputs , results )
- Formats the `inputs` and `results` arguments as a
[function type](LangRef.md#function-type).
[function type](Dialects/Builtin.md/#functiontype).
- The constraints on `inputs` and `results` are the same as the `input` of
the `type` directive.
@@ -814,7 +814,7 @@ def ReturnOp : ... {
##### Unit Attributes
In MLIR, the [`unit` Attribute](LangRef.md#unit-attribute) is special in that it
In MLIR, the [`unit` Attribute](Dialects/Builtin.md/#unitattr) is special in that it
only has one possible value, i.e. it derives meaning from its existence. When a
unit attribute is used to anchor an optional group and is not the first element
of the group, the presence of the unit attribute can be directly correlated with
@@ -1753,7 +1753,7 @@ very helpful way to understand and debug issues. To build `mlir-tblgen`, run
`cmake --build . --target mlir-tblgen` in your build directory and find the
`mlir-tblgen` binary in the `bin/` subdirectory. All the supported generators
can be found via `mlir-tblgen --help`. For example, `--gen-op-decls` and
`--gen-op-defs` as explained in [Generated C++ code](#generated-c++-code).
`--gen-op-defs` as explained in [Generated C++ code](#generated-c-code).
To see the generated code, invoke `mlir-tblgen` with a specific generator by
providing include paths via `-I`. For example,
@@ -1844,6 +1844,6 @@ requirements that were desirable:
[OpBase]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/OpBase.td
[OpDefinitionsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
[EnumsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/EnumsGen.cpp
[StringAttr]: LangRef.md#string-attribute
[IntegerAttr]: LangRef.md#integer-attribute
[StringAttr]: Dialects/Builtin.md/#stringattr
[IntegerAttr]: Dialects/Builtin.md/#integertype
[AttrClasses]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/Attributes.h

12
mlir/docs/PassManagement.md
View File

@@ -16,7 +16,7 @@ this is a great place to start.
## Operation Pass
In MLIR, the main unit of abstraction and transformation is an
[operation](LangRef.md#operations). As such, the pass manager is designed to
[operation](LangRef.md/#operations). As such, the pass manager is designed to
work on instances of operations at different levels of nesting. The structure of
the [pass manager](#pass-manager), and the concept of nesting, is detailed
further below. All passes in MLIR derive from `OperationPass` and adhere to the
@@ -98,8 +98,8 @@ is added to. This means that passes of this type may operate on several
different operation types. Passes of this type are generally written generically
using operation [interfaces](Interfaces.md) and [traits](Traits.md). Examples of
this type of pass are
[Common Sub-Expression Elimination](Passes.md#-cse-eliminate-common-sub-expressions)
and [Inlining](Passes.md#-inline-inline-function-calls).
[Common Sub-Expression Elimination](Passes.md/#-cse-eliminate-common-sub-expressions)
and [Inlining](Passes.md/#-inline-inline-function-calls).
To create an operation pass, a derived class must adhere to the following:
@@ -298,7 +298,7 @@ operation of a specific type. This operation type must adhere to the following
requirement:
* Must be registered and marked
[`IsolatedFromAbove`](Traits.md#isolatedfromabove).
[`IsolatedFromAbove`](Traits.md/#isolatedfromabove).
* Passes are expected to not modify operations at or above the current
operation being processed. If the operation is not isolated, it may
@@ -314,7 +314,7 @@ another existing `OpPassManager` via the `nest<>` method. This method takes the
operation type that the nested pass manager will operate on. At the top-level, a
`PassManager` acts as an `OpPassManager`. Nesting in this sense, corresponds to
the [structural](Tutorials/UnderstandingTheIRStructure.md) nesting within
[Regions](LangRef.md#regions) of the IR.
[Regions](LangRef.md/#regions) of the IR.
For example, the following `.mlir`:
@@ -393,7 +393,7 @@ program has been run through the passes. This provides several benefits:
In some situations it may be useful to run a pass pipeline within another pass,
to allow configuring or filtering based on some invariants of the current
operation being operated on. For example, the
[Inliner Pass](Passes.md#-inline-inline-function-calls) may want to run
[Inliner Pass](Passes.md/#-inline-inline-function-calls) may want to run
intraprocedural simplification passes while it is inlining to produce a better
cost model, and provide more optimal inlining. To enable this, passes may run an
arbitrary `OpPassManager` on the current operation being operated on or any

2
mlir/docs/PatternRewriter.md
View File

@@ -310,4 +310,4 @@ initial worklist with a postorder traversal of the region tree. This may
match larger patterns with ambiguous pattern sets.
Note: This driver is the one used by the [canonicalization](Canonicalization.md)
[pass](Passes.md#-canonicalize-canonicalize-operations) in MLIR.
[pass](Passes.md/#-canonicalize-canonicalize-operations) in MLIR.

4
mlir/docs/Quantization.md
View File

@@ -173,10 +173,10 @@ MLIR:
mapping between *expressed* values (typically of a floating point
computer type) and *storage* values (typically of an integral computer
type).
* [Type conversion ops](#quantized-type-conversion-ops) for converting
* [Type conversion ops](#quantized-type-conversion-operations) for converting
between types based on a QuantizedType and its *expressed* and *storage*
sub-types.
* [Instrumentation ops](#instrumentation-and-constraint-ops) for assigning
* [Instrumentation ops](#instrumentation-and-constraint-operations) for assigning
instrumentation points within the computation where runtime statistics
may help guide the quantization process.

10
mlir/docs/SPIRVToLLVMDialectConversion.md
View File

@@ -55,7 +55,7 @@ end of the array. Therefore, runtime array can be implemented as a zero length
array type.
Moreover, SPIR-V supports the notion of array stride. Currently only natural
strides (based on [`VulkanLayoutUtils`](VulkanLayoutUtils)) are supported. They
strides (based on [`VulkanLayoutUtils`][VulkanLayoutUtils]) are supported. They
are also mapped to LLVM array.
SPIR-V Dialect | LLVM Dialect
@@ -500,7 +500,7 @@ The SPIR-V to LLVM conversion does not involve modelling of workgroups.
Hence, we say that only current invocation is in conversion's scope. This means
that global variables with pointers of `Input`, `Output`, and `Private` storage
classes are supported. Also, `StorageBuffer` storage class is allowed for
executing [`mlir-spirv-cpu-runner`](#`mlir-spirv-cpu-runner`).
executing [`mlir-spirv-cpu-runner`](#mlir-spirv-cpu-runner).
Moreover, `bind` that specifies the descriptor set and the binding number and
`built_in` that specifies SPIR-V `BuiltIn` decoration have no conversion into
@@ -780,10 +780,10 @@ to LLVM dialect.
### `spv.func`
This op declares or defines a SPIR-V function and it is converted to `llvm.func`.
This conversion handles signature conversion, and function control attributes
remapping to LLVM dialect function [`passthrough` attribute](Dialects/LLVM.md#Attribute-pass-through).
remapping to LLVM dialect function [`passthrough` attribute](Dialects/LLVM.md/#attribute-pass-through).
The following mapping is used to map [SPIR-V function control](SPIRVFunctionAttributes) to
[LLVM function attributes](LLVMFunctionAttributes):
The following mapping is used to map [SPIR-V function control][SPIRVFunctionAttributes] to
[LLVM function attributes][LLVMFunctionAttributes]:
SPIR-V Function Control Attributes | LLVM Function Attributes
:-----------------------------------: | :-----------------------------------:

20
mlir/docs/SymbolsAndSymbolTables.md
View File

@@ -2,13 +2,13 @@
[TOC]
With [Regions](LangRef.md#regions), the multi-level aspect of MLIR is structural
With [Regions](LangRef.md/#regions), the multi-level aspect of MLIR is structural
in the IR. A lot of infrastructure within the compiler is built around this
nesting structure; including the processing of operations within the
[pass manager](PassManagement.md#pass-manager). One advantage of the MLIR design
[pass manager](PassManagement.md/#pass-manager). One advantage of the MLIR design
is that it is able to process operations in parallel, utilizing multiple
threads. This is possible due to a property of the IR known as
[`IsolatedFromAbove`](Traits.md#isolatedfromabove).
[`IsolatedFromAbove`](Traits.md/#isolatedfromabove).
Without this property, any operation could affect or mutate the use-list of
operations defined above. Making this thread-safe requires expensive locking in
@@ -31,9 +31,9 @@ defines a [`SymbolTable`](#symbol-table). The name of a symbol *must* be unique
within the parent `SymbolTable`. This name is semantically similarly to an SSA
result value, and may be referred to by other operations to provide a symbolic
link, or use, to the symbol. An example of a `Symbol` operation is
[`func`](LangRef.md#functions). `func` defines a symbol name, which is
[`func`](Dialects/Builtin.md/#func-mlirfuncop). `func` defines a symbol name, which is
[referred to](#referencing-a-symbol) by operations like
[`std.call`](Dialects/Standard.md#call).
[`std.call`](Dialects/Standard.md/#stdcall-callop).
### Defining or declaring a Symbol
@@ -67,7 +67,7 @@ Operations defining a `SymbolTable` must use the `OpTrait::SymbolTable` trait.
### Referencing a Symbol
`Symbol`s are referenced symbolically by name via the
[`SymbolRefAttr`](LangRef.md#symbol-reference-attribute) attribute. A symbol
[`SymbolRefAttr`](Dialects/Builtin.md/#symbolrefattr) attribute. A symbol
reference attribute contains a named reference to an operation that is nested
within a symbol table. It may optionally contain a set of nested references that
further resolve to a symbol nested within a different symbol table. When
@@ -118,8 +118,8 @@ module @module_symbol {
Using an attribute, as opposed to an SSA value, has several benefits:
* References may appear in more places than the operand list; including
[nested attribute dictionaries](LangRef.md#dictionary-attribute),
[array attributes](LangRef.md#array-attribute), etc.
[nested attribute dictionaries](Dialects/Builtin.md/dictionaryattr),
[array attributes](Dialects/Builtin.md/#arrayattr), etc.
* Handling of SSA dominance remains unchanged.
@@ -138,11 +138,11 @@ different trade offs depending on the situation. A function call may directly
use a `SymbolRef` as the callee, whereas a reference to a global variable might
use a materialization operation so that the variable can be used in other
operations like `std.addi`.
[`llvm.mlir.addressof`](Dialects/LLVM.md#llvmmliraddressof) is one example of
[`llvm.mlir.addressof`](Dialects/LLVM.md/#llvmmliraddressof-mlirllvmaddressofop) is one example of
such an operation.
See the `LangRef` definition of the
[`SymbolRefAttr`](LangRef.md#symbol-reference-attribute) for more information
[`SymbolRefAttr`](Dialects/Builtin.md/#symbolrefattr) for more information
about the structure of this attribute.
Operations that reference a `Symbol` and want to perform verification and

2
mlir/docs/Traits.md
View File

@@ -211,7 +211,7 @@ are nested inside of other operations that themselves have this trait.
This trait is carried by region holding operations that define a new scope for
automatic allocation. Such allocations are automatically freed when control is
transferred back from the regions of such operations. As an example, allocations
performed by [`memref.alloca`](Dialects/MemRef.md#memrefalloca-allocaop) are
performed by [`memref.alloca`](Dialects/MemRef.md/#memrefalloca-mlirmemrefallocaop) are
automatically freed when control leaves the region of its closest surrounding op
that has the trait AutomaticAllocationScope.

2
mlir/include/mlir/IR/RegionKindInterface.td
View File

@@ -23,7 +23,7 @@ def RegionKindInterface : OpInterface<"RegionKindInterface"> {
their regions. Currently, two kinds of regions are
supported. RegionKind::Graph represents a graph region without
control flow semantics. RegionKind::SSACFG represents an
[SSA-style control flow](LangRef.md#modeling-control-flow) region
[SSA-style control flow](../LangRef.md/#modeling-control-flow) region
with basic blocks, sequential semantics, and reachability.
}];
let cppNamespace = "::mlir";

2
mlir/include/mlir/IR/SymbolInterfaces.td
View File

@@ -24,7 +24,7 @@ def Symbol : OpInterface<"SymbolOpInterface"> {
let description = [{
This interface describes an operation that may define a `Symbol`. A `Symbol`
operation resides immediately within a region that defines a `SymbolTable`.
See [Symbols and SymbolTables](SymbolsAndSymbolTables.md) for more details
See [Symbols and SymbolTables](../SymbolsAndSymbolTables.md) for more details
and constraints on `Symbol` operations.
}];
let cppNamespace = "::mlir";