• Home
  • History
  • Annotate
  • Raw
  • Download

Lines Matching +full:method +full:- +full:complexity

6 form a graph-based data structure, and the compiler analyses and passes
12 `const` entirely for the core IR types: you should never see a `const` method on
14 about this. That said, you *should* use `const` for non-IR types, like
29 > the optimization needs to get a non-`const` pointer. So all analyses either
33 > are all bad, probably so bad as to out-weigh the benefits of const.
37 This document argues this design is introducing significant sub-optimalities
39 a poor tradeoff, and proposes switching to a much simpler approach - eliminating
51 casting (of various sorts) to check for patterns, and use some high-abstraction
68 // A non-const instruction returns a non-const parent pointer.
75 The rationale for this design is that it would be const-incorrect to return a
76 non-const pointer from getParent, because you could then walk the block to find
77 the instruction again and get non-const references to the same instruction - all
85 IR object and bind a non-const IR object.
90 of the model aren't worth the cost of the complexity, or 3) both 1 and 2,
93 ## Advantages of Const-correctness in MLIR
101 the dominator APIs have a `dominates(const Block*, const Block*)` method, and
103 passed in - similarly predicates like `Instruction::isTerminator() const` do not
110 ## Costs of Const-correctness in MLIR
113 allowing const-correct traversals in the APIs. Here we discuss the various costs
120 that all of the graph traversal accessors be duplicated into const and non-const
163 A related issue is that having to provide both const and non-const versions of
166 are templates *_only_* because they are generic over const and non-const
170 Thus, our const model is leading to more code in headers and more complexity in
182 and non-const values. Actually fixing this would cause massive code bloat and
183 complexity.
194 While it makes sense for a clone method to be `const` conceptually (the original
206 However, this is a problem for our current `const` design - `const DimOp` means
228 if (auto *dimOp = inst->dyn_cast<DimOp>()) {
263 1. All of the const-duplicated accessors would be eliminated, e.g.
266 1. Const-only predicates would be changed to be non-const, e.g.