[Mlir-commits] [mlir] [mlir] Add concept of alias blocks (PR #65503)

Markus Böck llvmlistbot at llvm.org
Mon Sep 18 10:43:14 PDT 2023


================
@@ -79,6 +82,9 @@ ParseResult Parser::parseFusedLocation(LocationAttr &loc) {
     LocationAttr newLoc;
     if (parseLocationInstance(newLoc))
       return failure();
+    if (syntaxOnly())
----------------
zero9178 wrote:

I ruled out the deferred aliases approach as not implementable.
The way it works for locations is that a placeholder location is created that is then later RAUW with the actual location at the end of the module.

The reason I don't think is implementable is because todays attributes and types would not be able to handle having some placeholder returned from `parseType` or `parseAttribute` as they tend to check that these are of specific kinds (e.g. `IntegerAttr` or `MemRefElementTypeInterface` or fullfill some other specific constraints.
See also https://discourse.llvm.org/t/rfc-supporting-aliases-in-cyclic-types-and-attributes/73236#return-placeholder-attributes-or-types-10

I agree that this is invasive and I'd love to hear better options. I initially considered writing separate `skipType` and `skipAttr` functions, but there I'd essentially just end up reimplementing the whole parser for the builtin attributes, including error messages, which would lead to a lot of code duplications. Any other way of skipping that isn't based on actually parsing the syntactic elements I'd consider more of a "hack" that is prone to breaking.

The silver lining is that this logic and invasiveness is private to the parser implementation and not user exposed and only part of the *builtin* attribute and type parsing, not any dialect parsing.

https://github.com/llvm/llvm-project/pull/65503


More information about the Mlir-commits mailing list