1# Interfaces 2 3MLIR is a generic and extensible framework, representing different dialects with 4their own attributes, operations, types, and so on. MLIR Dialects can express 5operations with a wide variety of semantics and different levels of abstraction. 6The downside to this is that MLIR transformations and analyses need to be able 7to account for the semantics of every operation, or be overly conservative. 8Without care, this can result in code with special-cases for each supported 9operation type. To combat this, MLIR provides a concept of `interfaces`. 10 11## Motivation 12 13Interfaces provide a generic way of interacting with the IR. The goal is to be 14able to express transformations/analyses in terms of these interfaces without 15encoding specific knowledge about the exact operation or dialect involved. This 16makes the compiler more easily extensible by allowing the addition of new 17dialects and operations in a decoupled way with respect to the implementation of 18transformations/analyses. 19 20### Dialect Interfaces 21 22Dialect interfaces are generally useful for transformation passes or analyses 23that want to operate generically on a set of attributes/operations/types, which 24may be defined in different dialects. These interfaces generally involve wide 25coverage over an entire dialect and are only used for a handful of analyses or 26transformations. In these cases, registering the interface directly on each 27operation is overly complex and cumbersome. The interface is not core to the 28operation, just to the specific transformation. An example of where this type of 29interface would be used is inlining. Inlining generally queries high-level 30information about the operations within a dialect, like cost modeling and 31legality, that often is not specific to one operation. 32 33A dialect interface can be defined by inheriting from the 34[CRTP](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) base 35class `DialectInterfaceBase::Base<>`. This class provides the necessary 36utilities for registering an interface with a dialect so that it can be 37referenced later. Once the interface has been defined, dialects can override it 38using dialect-specific information. The interfaces defined by a dialect are 39registered via `addInterfaces<>`, a similar mechanism to Attributes, Operations, 40Types, etc 41 42```c++ 43/// Define a base inlining interface class to allow for dialects to opt-in to 44/// the inliner. 45class DialectInlinerInterface : 46 public DialectInterface::Base<DialectInlinerInterface> { 47public: 48 /// Returns true if the given region 'src' can be inlined into the region 49 /// 'dest' that is attached to an operation registered to the current dialect. 50 /// 'valueMapping' contains any remapped values from within the 'src' region. 51 /// This can be used to examine what values will replace entry arguments into 52 /// the 'src' region, for example. 53 virtual bool isLegalToInline(Region *dest, Region *src, 54 BlockAndValueMapping &valueMapping) const { 55 return false; 56 } 57}; 58 59/// Override the inliner interface to add support for the AffineDialect to 60/// enable inlining affine operations. 61struct AffineInlinerInterface : public DialectInlinerInterface { 62 /// Affine structures have specific inlining constraints. 63 bool isLegalToInline(Region *dest, Region *src, 64 BlockAndValueMapping &valueMapping) const final { 65 ... 66 } 67}; 68 69/// Register the interface with the dialect. 70AffineDialect::AffineDialect(MLIRContext *context) ... { 71 addInterfaces<AffineInlinerInterface>(); 72} 73``` 74 75Once registered, these interfaces can be queried from the dialect by an analysis 76or transformation without the need to determine the specific dialect subclass: 77 78```c++ 79Dialect *dialect = ...; 80if (DialectInlinerInterface *interface 81 = dialect->getRegisteredInterface<DialectInlinerInterface>()) { 82 // The dialect has provided an implementation of this interface. 83 ... 84} 85``` 86 87#### DialectInterfaceCollection 88 89An additional utility is provided via `DialectInterfaceCollection`. This class 90allows for collecting all of the dialects that have registered a given interface 91within an instance of the `MLIRContext`. This can be useful to hide and optimize 92the lookup of a registered dialect interface. 93 94```c++ 95class InlinerInterface : public 96 DialectInterfaceCollection<DialectInlinerInterface> { 97 /// The hooks for this class mirror the hooks for the DialectInlinerInterface, 98 /// with default implementations that call the hook on the interface for a 99 /// given dialect. 100 virtual bool isLegalToInline(Region *dest, Region *src, 101 BlockAndValueMapping &valueMapping) const { 102 auto *handler = getInterfaceFor(dest->getContainingOp()); 103 return handler ? handler->isLegalToInline(dest, src, valueMapping) : false; 104 } 105}; 106 107MLIRContext *ctx = ...; 108InlinerInterface interface(ctx); 109if(!interface.isLegalToInline(...)) 110 ... 111``` 112 113### Attribute/Operation/Type Interfaces 114 115Attribute/Operation/Type interfaces, as the names suggest, are those registered 116at the level of a specific attribute/operation/type. These interfaces provide 117access to derived objects by providing a virtual interface that must be 118implemented. As an example, many analyses and transformations want to reason 119about the side effects of an operation to improve performance and correctness. 120The side effects of an operation are generally tied to the semantics of a 121specific operation, for example an `affine.load` operation has a `read` effect 122(as the name may suggest). 123 124These interfaces are defined by overriding the 125[CRTP](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) class 126for the specific IR entity; `AttrInterface`, `OpInterface`, or `TypeInterface` 127respectively. These classes take, as a template parameter, a `Traits` class that 128defines a `Concept` and a `Model` class. These classes provide an implementation 129of concept-based polymorphism, where the `Concept` defines a set of virtual 130methods that are overridden by the `Model` that is templated on the concrete 131entity type. It is important to note that these classes should be pure, and 132should not contain non-static data members or other mutable data. To attach an 133interface to an object, the base interface classes provide a 134[`Trait`](Traits.md) class that can be appended to the trait list of that 135object. 136 137```c++ 138struct ExampleOpInterfaceTraits { 139 /// Define a base concept class that specifies the virtual interface to be 140 /// implemented. 141 struct Concept { 142 virtual ~Concept(); 143 144 /// This is an example of a non-static hook to an operation. 145 virtual unsigned exampleInterfaceHook(Operation *op) const = 0; 146 147 /// This is an example of a static hook to an operation. A static hook does 148 /// not require a concrete instance of the operation. The implementation is 149 /// a virtual hook, the same as the non-static case, because the 150 /// implementation of the hook itself still requires indirection. 151 virtual unsigned exampleStaticInterfaceHook() const = 0; 152 }; 153 154 /// Define a model class that specializes a concept on a given operation type. 155 template <typename ConcreteOp> 156 struct Model : public Concept { 157 /// Override the method to dispatch on the concrete operation. 158 unsigned exampleInterfaceHook(Operation *op) const final { 159 return llvm::cast<ConcreteOp>(op).exampleInterfaceHook(); 160 } 161 162 /// Override the static method to dispatch to the concrete operation type. 163 unsigned exampleStaticInterfaceHook() const final { 164 return ConcreteOp::exampleStaticInterfaceHook(); 165 } 166 }; 167}; 168 169/// Define the main interface class that analyses and transformations will 170/// interface with. 171class ExampleOpInterface : public OpInterface<ExampleOpInterface, 172 ExampleOpInterfaceTraits> { 173public: 174 /// Inherit the base class constructor to support LLVM-style casting. 175 using OpInterface<ExampleOpInterface, ExampleOpInterfaceTraits>::OpInterface; 176 177 /// The interface dispatches to 'getImpl()', a method provided by the base 178 /// `OpInterface` class that returns an instance of the concept. 179 unsigned exampleInterfaceHook() const { 180 return getImpl()->exampleInterfaceHook(getOperation()); 181 } 182 unsigned exampleStaticInterfaceHook() const { 183 return getImpl()->exampleStaticInterfaceHook(getOperation()->getName()); 184 } 185}; 186 187``` 188 189Once the interface has been defined, it is registered to an operation by adding 190the provided trait `ExampleOpInterface::Trait` as described earlier. Using this 191interface is just like using any other derived operation type, i.e. casting: 192 193```c++ 194/// When defining the operation, the interface is registered via the nested 195/// 'Trait' class provided by the 'OpInterface<>' base class. 196class MyOp : public Op<MyOp, ExampleOpInterface::Trait> { 197public: 198 /// The definition of the interface method on the derived operation. 199 unsigned exampleInterfaceHook() { return ...; } 200 static unsigned exampleStaticInterfaceHook() { return ...; } 201}; 202 203/// Later, we can query if a specific operation(like 'MyOp') overrides the given 204/// interface. 205Operation *op = ...; 206if (ExampleOpInterface example = dyn_cast<ExampleOpInterface>(op)) 207 llvm::errs() << "hook returned = " << example.exampleInterfaceHook() << "\n"; 208``` 209 210#### External Models for Attribute, Operation and Type Interfaces 211 212It may be desirable to provide an interface implementation for an IR object 213without modifying the definition of said object. Notably, this allows to 214implement interfaces for attributes, operations and types outside of the dialect 215that defines them, for example, to provide interfaces for built-in types. 216 217This is achieved by extending the concept-based polymorphism model with two more 218classes derived from `Concept` as follows. 219 220```c++ 221struct ExampleTypeInterfaceTraits { 222 struct Concept { 223 virtual unsigned exampleInterfaceHook(Type type) const = 0; 224 virtual unsigned exampleStaticInterfaceHook() const = 0; 225 }; 226 227 template <typename ConcreteType> 228 struct Model : public Concept { /*...*/ }; 229 230 /// Unlike `Model`, `FallbackModel` passes the type object through to the 231 /// hook, making it accessible in the method body even if the method is not 232 /// defined in the class itself and thus has no `this` access. ODS 233 /// automatically generates this class for all interfaces. 234 template <typename ConcreteType> 235 struct FallbackModel : public Concept { 236 unsigned exampleInterfaceHook(Type type) const override { 237 getImpl()->exampleInterfaceHook(type); 238 } 239 unsigned exampleStaticInterfaceHook() const override { 240 ConcreteType::exampleStaticInterfaceHook(); 241 } 242 }; 243 244 /// `ExternalModel` provides a place for default implementations of interface 245 /// methods by explicitly separating the model class, which implements the 246 /// interface, from the type class, for which the interface is being 247 /// implemented. Default implementations can be then defined generically 248 /// making use of `cast<ConcreteType>`. If `ConcreteType` does not provide 249 /// the APIs required by the default implementation, custom implementations 250 /// may use `FallbackModel` directly to override the default implementation. 251 /// Being located in a class template, it never gets instantiated and does not 252 /// lead to compilation errors. ODS automatically generates this class and 253 /// places default method implementations in it. 254 template <typename ConcreteModel, typename ConcreteType> 255 struct ExternalModel : public FallbackModel<ConcreteModel> { 256 unsigned exampleInterfaceHook(Type type) const override { 257 // Default implementation can be provided here. 258 return type.cast<ConcreteType>().callSomeTypeSpecificMethod(); 259 } 260 }; 261}; 262``` 263 264External models can be provided for attribute, operation and type interfaces by 265deriving either `FallbackModel` or `ExternalModel` and by registering the model 266class with the relevant class in a given context. Other contexts will not see 267the interface unless registered. 268 269```c++ 270/// External interface implementation for a concrete class. This does not 271/// require modifying the definition of the type class itself. 272struct ExternalModelExample 273 : public ExampleTypeInterface::ExternalModel<ExternalModelExample, 274 IntegerType> { 275 static unsigned exampleStaticInterfaceHook() { 276 // Implementation is provided here. 277 return IntegerType::someStaticMethod(); 278 } 279 280 // No need to define `exampleInterfaceHook` that has a default implementation 281 // in `ExternalModel`. But it can be overridden if desired. 282} 283 284int main() { 285 MLIRContext context; 286 /* ... */; 287 288 // Register the interface model with the type in the given context before 289 // using it. The dialect contaiing the type is expected to have been loaded 290 // at this point. 291 IntegerType::registerInterface<ExternalModelExample>(context); 292} 293``` 294 295Note: It is strongly encouraged to only use this mechanism if you "own" the 296interface being externally applied. This prevents a situation where neither the 297owner of the dialect containing the object nor the owner of the interface are 298aware of an interface implementation, which can lead to duplicate or 299diverging implementations. 300 301#### Dialect Fallback for OpInterface 302 303Some dialects have an open ecosystem and don't register all of the possible 304operations. In such cases it is still possible to provide support for 305implementing an `OpInterface` for these operation. When an operation isn't 306registered or does not provide an implementation for an interface, the query 307will fallback to the dialect itself. 308 309A second model is used for such cases and automatically generated when using ODS 310(see below) with the name `FallbackModel`. This model can be implemented for a 311particular dialect: 312 313```c++ 314// This is the implementation of a dialect fallback for `ExampleOpInterface`. 315struct FallbackExampleOpInterface 316 : public ExampleOpInterface::FallbackModel< 317 FallbackExampleOpInterface> { 318 static bool classof(Operation *op) { return true; } 319 320 unsigned exampleInterfaceHook(Operation *op) const; 321 unsigned exampleStaticInterfaceHook() const; 322}; 323``` 324 325A dialect can then instantiate this implementation and returns it on specific 326operations by overriding the `getRegisteredInterfaceForOp` method : 327 328```c++ 329void *TestDialect::getRegisteredInterfaceForOp(TypeID typeID, 330 Identifier opName) { 331 if (typeID == TypeID::get<ExampleOpInterface>()) { 332 if (isSupported(opName)) 333 return fallbackExampleOpInterface; 334 return nullptr; 335 } 336 return nullptr; 337} 338``` 339 340#### Utilizing the ODS Framework 341 342Note: Before reading this section, the reader should have some familiarity with 343the concepts described in the 344[`Operation Definition Specification`](OpDefinitions.md) documentation. 345 346As detailed above, [Interfaces](#attributeoperationtype-interfaces) allow for 347attributes, operations, and types to expose method calls without requiring that 348the caller know the specific derived type. The downside to this infrastructure, 349is that it requires a bit of boiler plate to connect all of the pieces together. 350MLIR provides a mechanism with which to defines interfaces declaratively in ODS, 351and have the C++ definitions auto-generated. 352 353As an example, using the ODS framework would allow for defining the example 354interface above as: 355 356```tablegen 357def ExampleOpInterface : OpInterface<"ExampleOpInterface"> { 358 let description = [{ 359 This is an example interface definition. 360 }]; 361 362 let methods = [ 363 InterfaceMethod< 364 "This is an example of a non-static hook to an operation.", 365 "unsigned", "exampleInterfaceHook" 366 >, 367 StaticInterfaceMethod< 368 "This is an example of a static hook to an operation.", 369 "unsigned", "exampleStaticInterfaceHook" 370 >, 371 ]; 372} 373``` 374 375Providing a definition of the `AttrInterface`, `OpInterface`, or `TypeInterface` 376class will auto-generate the C++ classes for the interface. Interfaces are 377comprised of the following components: 378 379* C++ Class Name (Provided via template parameter) 380 - The name of the C++ interface class. 381* Description (`description`) 382 - A string description of the interface, its invariants, example usages, 383 etc. 384* C++ Namespace (`cppNamespace`) 385 - The C++ namespace that the interface class should be generated in. 386* Methods (`methods`) 387 - The list of interface hook methods that are defined by the IR object. 388 - The structure of these methods is defined below. 389* Extra Class Declarations (Optional: `extraClassDeclaration`) 390 - Additional C++ code that is generated in the declaration of the 391 interface class. This allows for defining methods and more on the user 392 facing interface class, that do not need to hook into the IR entity. 393 These declarations are _not_ implicitly visible in default 394 implementations of interface methods, but static declarations may be 395 accessed with full name qualification. 396 397`OpInterface` classes may additionally contain the following: 398 399* Verifier (`verify`) 400 - A C++ code block containing additional verification applied to the 401 operation that the interface is attached to. 402 - The structure of this code block corresponds 1-1 with the structure of a 403 [`Trait::verifyTrait`](Traits.md) method. 404 405There are two types of methods that can be used with an interface, 406`InterfaceMethod` and `StaticInterfaceMethod`. They are both comprised of the 407same core components, with the distinction that `StaticInterfaceMethod` models a 408static method on the derived IR object. 409 410Interface methods are comprised of the following components: 411 412* Description 413 - A string description of this method, its invariants, example usages, 414 etc. 415* ReturnType 416 - A string corresponding to the C++ return type of the method. 417* MethodName 418 - A string corresponding to the C++ name of the method. 419* Arguments (Optional) 420 - A dag of strings that correspond to a C++ type and variable name 421 respectively. 422* MethodBody (Optional) 423 - An optional explicit implementation of the interface method. 424 - This implementation is placed within the method defined on the `Model` 425 traits class, and is not defined by the `Trait` class that is attached 426 to the IR entity. More concretely, this body is only visible by the 427 interface class and does not affect the derived IR entity. 428 - `ConcreteAttr`/`ConcreteOp`/`ConcreteType` is an implicitly defined 429 `typename` that can be used to refer to the type of the derived IR 430 entity currently being operated on. 431 - In non-static methods, `$_op` and `$_self` may be used to refer to an 432 instance of the derived IR entity. 433* DefaultImplementation (Optional) 434 - An optional explicit default implementation of the interface method. 435 - This implementation is placed within the `Trait` class that is attached 436 to the IR entity, and does not directly affect any of the interface 437 classes. As such, this method has the same characteristics as any other 438 [`Trait`](Traits.md) method. 439 - `ConcreteAttr`/`ConcreteOp`/`ConcreteType` is an implicitly defined 440 `typename` that can be used to refer to the type of the derived IR 441 entity currently being operated on. 442 - This may refer to static fields of the interface class using the 443 qualified name, e.g., `TestOpInterface::staticMethod()`. 444 445ODS also allows for generating declarations for the `InterfaceMethod`s of an 446operation if the operation specifies the interface with 447`DeclareOpInterfaceMethods` (see an example below). 448 449Examples: 450 451~~~tablegen 452def MyInterface : OpInterface<"MyInterface"> { 453 let description = [{ 454 This is the description of the interface. It provides concrete information 455 on the semantics of the interface, and how it may be used by the compiler. 456 }]; 457 458 let methods = [ 459 InterfaceMethod<[{ 460 This method represents a simple non-static interface method with no 461 inputs, and a void return type. This method is required to be implemented 462 by all operations implementing this interface. This method roughly 463 correlates to the following on an operation implementing this interface: 464 465 ```c++ 466 class ConcreteOp ... { 467 public: 468 void nonStaticMethod(); 469 }; 470 ``` 471 }], "void", "nonStaticMethod" 472 >, 473 474 InterfaceMethod<[{ 475 This method represents a non-static interface method with a non-void 476 return value, as well as an `unsigned` input named `i`. This method is 477 required to be implemented by all operations implementing this interface. 478 This method roughly correlates to the following on an operation 479 implementing this interface: 480 481 ```c++ 482 class ConcreteOp ... { 483 public: 484 Value nonStaticMethod(unsigned i); 485 }; 486 ``` 487 }], "Value", "nonStaticMethodWithParams", (ins "unsigned":$i) 488 >, 489 490 StaticInterfaceMethod<[{ 491 This method represents a static interface method with no inputs, and a 492 void return type. This method is required to be implemented by all 493 operations implementing this interface. This method roughly correlates 494 to the following on an operation implementing this interface: 495 496 ```c++ 497 class ConcreteOp ... { 498 public: 499 static void staticMethod(); 500 }; 501 ``` 502 }], "void", "staticMethod" 503 >, 504 505 StaticInterfaceMethod<[{ 506 This method corresponds to a static interface method that has an explicit 507 implementation of the method body. Given that the method body has been 508 explicitly implemented, this method should not be defined by the operation 509 implementing this method. This method merely takes advantage of properties 510 already available on the operation, in this case its `build` methods. This 511 method roughly correlates to the following on the interface `Model` class: 512 513 ```c++ 514 struct InterfaceTraits { 515 /// ... The `Concept` class is elided here ... 516 517 template <typename ConcreteOp> 518 struct Model : public Concept { 519 Operation *create(OpBuilder &builder, Location loc) const override { 520 return builder.create<ConcreteOp>(loc); 521 } 522 } 523 }; 524 ``` 525 526 Note above how no modification is required for operations implementing an 527 interface with this method. 528 }], 529 "Operation *", "create", (ins "OpBuilder &":$builder, "Location":$loc), 530 /*methodBody=*/[{ 531 return builder.create<ConcreteOp>(loc); 532 }]>, 533 534 InterfaceMethod<[{ 535 This method represents a non-static method that has an explicit 536 implementation of the method body. Given that the method body has been 537 explicitly implemented, this method should not be defined by the operation 538 implementing this method. This method merely takes advantage of properties 539 already available on the operation, in this case its `build` methods. This 540 method roughly correlates to the following on the interface `Model` class: 541 542 ```c++ 543 struct InterfaceTraits { 544 /// ... The `Concept` class is elided here ... 545 546 template <typename ConcreteOp> 547 struct Model : public Concept { 548 Operation *create(Operation *opaqueOp, OpBuilder &builder, 549 Location loc) const override { 550 ConcreteOp op = cast<ConcreteOp>(opaqueOp); 551 return op.getNumInputs() + op.getNumOutputs(); 552 } 553 } 554 }; 555 ``` 556 557 Note above how no modification is required for operations implementing an 558 interface with this method. 559 }], 560 "unsigned", "getNumInputsAndOutputs", (ins), /*methodBody=*/[{ 561 return $_op.getNumInputs() + $_op.getNumOutputs(); 562 }]>, 563 564 InterfaceMethod<[{ 565 This method represents a non-static method that has a default 566 implementation of the method body. This means that the implementation 567 defined here will be placed in the trait class that is attached to every 568 operation that implements this interface. This has no effect on the 569 generated `Concept` and `Model` class. This method roughly correlates to 570 the following on the interface `Trait` class: 571 572 ```c++ 573 template <typename ConcreteOp> 574 class MyTrait : public OpTrait::TraitBase<ConcreteType, MyTrait> { 575 public: 576 bool isSafeToTransform() { 577 ConcreteOp op = cast<ConcreteOp>(this->getOperation()); 578 return op.getNumInputs() + op.getNumOutputs(); 579 } 580 }; 581 ``` 582 583 As detailed in [Traits](Traits.md), given that each operation implementing 584 this interface will also add the interface trait, the methods on this 585 interface are inherited by the derived operation. This allows for 586 injecting a default implementation of this method into each operation that 587 implements this interface, without changing the interface class itself. If 588 an operation wants to override this default implementation, it merely 589 needs to implement the method and the derived implementation will be 590 picked up transparently by the interface class. 591 592 ```c++ 593 class ConcreteOp ... { 594 public: 595 bool isSafeToTransform() { 596 // Here we can override the default implementation of the hook 597 // provided by the trait. 598 } 599 }; 600 ``` 601 }], 602 "bool", "isSafeToTransform", (ins), /*methodBody=*/[{}], 603 /*defaultImplementation=*/[{ 604 }]>, 605 ]; 606} 607 608// Operation interfaces can optionally be wrapped inside 609// DeclareOpInterfaceMethods. This would result in autogenerating declarations 610// for members `foo`, `bar` and `fooStatic`. Methods with bodies are not 611// declared inside the op declaration but instead handled by the op interface 612// trait directly. 613def OpWithInferTypeInterfaceOp : Op<... 614 [DeclareOpInterfaceMethods<MyInterface>]> { ... } 615 616// Methods that have a default implementation do not have declarations 617// generated. If an operation wishes to override the default behavior, it can 618// explicitly specify the method that it wishes to override. This will force 619// the generation of a declaration for those methods. 620def OpWithOverrideInferTypeInterfaceOp : Op<... 621 [DeclareOpInterfaceMethods<MyInterface, ["getNumWithDefault"]>]> { ... } 622~~~ 623 624Note: Existing operation interfaces defined in C++ can be accessed in the ODS 625framework via the `OpInterfaceTrait` class. 626 627#### Operation Interface List 628 629MLIR includes standard interfaces providing functionality that is likely to be 630common across many different operations. Below is a list of some key interfaces 631that may be used directly by any dialect. The format of the header for each 632interface section goes as follows: 633 634* `Interface class name` 635 - (`C++ class` -- `ODS class`(if applicable)) 636 637##### CallInterfaces 638 639* `CallOpInterface` - Used to represent operations like 'call' 640 - `CallInterfaceCallable getCallableForCallee()` 641* `CallableOpInterface` - Used to represent the target callee of call. 642 - `Region * getCallableRegion()` 643 - `ArrayRef<Type> getCallableResults()` 644 645##### RegionKindInterfaces 646 647* `RegionKindInterface` - Used to describe the abstract semantics of regions. 648 - `RegionKind getRegionKind(unsigned index)` - Return the kind of the 649 region with the given index inside this operation. 650 - RegionKind::Graph - represents a graph region without control flow 651 semantics 652 - RegionKind::SSACFG - represents an 653 [SSA-style control flow](LangRef.md/#control-flow-and-ssacfg-regions) region 654 with basic blocks and reachability 655 - `hasSSADominance(unsigned index)` - Return true if the region with the 656 given index inside this operation requires dominance. 657 658##### SymbolInterfaces 659 660* `SymbolOpInterface` - Used to represent 661 [`Symbol`](SymbolsAndSymbolTables.md/#symbol) operations which reside 662 immediately within a region that defines a 663 [`SymbolTable`](SymbolsAndSymbolTables.md/#symbol-table). 664 665* `SymbolUserOpInterface` - Used to represent operations that reference 666 [`Symbol`](SymbolsAndSymbolTables.md/#symbol) operations. This provides the 667 ability to perform safe and efficient verification of symbol uses, as well 668 as additional functionality. 669